Operating Systems 2017F Lecture 12
Video
Video from the lecture given on October 17, 2017 is now available.
Notes
In-Class
Lecture 12 ---------- * segmentation * inode fields * page table entries * scheduling paging, blocks - fixed-sized memory allocations - typically 4K or 8K (can have some huge ones) paging only works well if you have MMU - need page tables, TLB - do "table lookup" on every memory access How do you manage memory without paging? * put everything at a fixed place in memory - useful if you have very little RAM * put code, data into "segments" - semantic units of memory (stack, heap, "text") - still use this terminology when referring to parts of a binary program Segments: * a variable-sized block of memory * base: starting address * bound: how long is it Key idea is segments can be placed in different parts of the address space - to move, you just change the base - code inside a segment refers to rest of segment via offsets - on each memory access, CPU adds segment register to offset to get physical address - having a base address with offsets is still used in userspace 16-bit x86 (8086) is a segmented architecture - memory accesses are mostly relative to a segment base address standard modes for 32-bit x86 (80386+) and 64-bit x86 (amd64) is "flat" - segmented memory can be a pain because it can "wrap around" - going past the last address can put you in the first, or it just gives you an error inode fields ------------ - stat, lstat gives you details on an inode - inodes allow access to contents of files and have the key metadata - size - "mode" - rwx, others - owner, group Users, groups ------------- users and groups are used to restrict access - each file has a user and group associated with it, permissions - each process has a user and group What if file ownership/permissions are "wrong"? In UNIX, the "root" user has all power - can bypass all permission checks - (unless you are on a mandatory access control system such as seLinux) - VERY DANGEROUS (Equivalent to an administrator account on Windows) Page table entries ------------------ page tables are "tables" (really very wide trees) of page table entries page table entries contain the top bits of the physical address along with metadata: - readable? - writable? - executable? most pages are either r+x (code) or r+w (data) - valid? - dirty? - is data in page different from data on disk? other bits to help with deciding what pages to keep in RAM or not - e.g., when was it last accessed
Additional Notes
Announcements You may want to use Openstack after midterm Semaphore tutorial is like kernel code Tutorial similar to assignment!
Additional Notes Segmentation Inode fields Page table entries Scheduling
Paging - fixed sized memory allocations of usually 4k or 8k blocks (cab have some larger ones)
Paging only works well if you have hardware to help you - specifically Memory Management Unit Need page tables, TLB (Translation Lookaside Buffer: memory cache that speeds up access time to a user memory lcoation) Do "table lookup" on every memory access
If you do not have full paging support how would you manage memory? Basic approach: put everything at a fixed place in memory Useful if you have limited RAM
Classic Way: Put code, data into "segments" instead of pages Semantic units of memory (stack, heap, "text") Execve loads segments into memory Still use this terminology when referring to parts of a binary program
Segments: Variable sized block of memory Base: starting address Bound: how long is it Key idea is segments can be placed in different parts of the address space: to move, you just change the base Code inside a segment refers to rest of segment via offsets On each memory access, CPU adds segment register to offset to get physical address Having a base address with offsets is still used in userspace
16-bit x86 (8086) is a segmented architecture Memory access is msotly relative toa segment base address Standard modes for 32-bit x86 (80386+) and 64-bit x86 (amd64) is "flat" things can be wherever Segmented memory can be a pain because it can "wrap around" - going past the last address can put you in the first, or it just gives error
Inode fields: Stat, lstat gives you details on an inode Inodes allows access to contents of files and have metadata such as indoe number, user id, stuff about time Size "Mode" - rwx (he shoes us how to change read write permissions the normal way and also using chmod number to set individual bits and also through GUI), others Owner, group
Xdg-open foo.js same as double clicking knows what preferred program to open a file
Users, groups Users and group are used to restrict access each file has a user and group associated with it, permissions Each process has a user and group What if file ownership/permissions are "wrong" Use "whoami" command to find user class
In UNIX root user has all power Can bypass all permission checks (Equivalent to Administrator on Windows) Dangerous because you can become another user and do anything You can view permission model in System Monitor and see processes owned by root, anilclass, etc. Regular users users cannot usually send kill commands to other processes. If you are the root no one else can send you a signal but you can have access to everything so very dangerous if attacker takes over root Id command calls getuid Kernel does not know where username is stored Hash function returns fixed size input over variable input and are used to securely store passwords. Even the hashes are stored in shadow files because you can password breach by guessing the password and hashing it and comparing it to the hashed password values. Lot of work but can be successful if you have a weak common password. There are rainbow tables that store some of the hashed passwords. Hashed password stored in etc\shadow
Page table entries Page tables are like tables (actually more like very wide trees) used to map virtual adrdress to phsyical address Contain top bits of physical address along with metadata Readable?, writable? - executable (contains binary code)? Most pages are either r+x(code) or r+w(data)