Outline COS 318: Operating Systems u Protection Mechanisms and OS Structures Protection and Virtual Memory u Virtual Memory: Protection and Address Translation Jaswinder Pal Singh and a Fabulous Course Staff Computer Science Department Princeton University (http://www.cs.princeton.edu/courses/cos318/) 2 Some Protection Goals Architecture Support for CPU Protection u CPU • Privileged Mode l Enable kernel to take CPU away to prevent a user from using CPU forever An interrupt or exception/trap (INT) l Users should not have this ability u Memory User mode Kernel (privileged) mode l Prevent a user from accessing others’ data • Regular instructions • Regular instructions • Access user memory • Privileged instructions l Prevent users from modifying kernel code and data • Access user memory structures • Access kernel memory u I/O l Prevent users from performing “illegal” I/Os A special instruction (IRET) u Question l What’s the difference between protection and security? 3 4 1 Privileged Instruction Examples OS Structures and Protection: Monolithic u Memory address mapping u All kernel routines are together, linked in single large executable u Flush or invalidate data cache l Each can call any other u Invalidate TLB entries l Services and utilities User User program program u Load and read system registers u Provides a system call API u u Change processor modes from kernel to user Examples: syscall l Linux, BSD Unix, Windows, … u Change the voltage and frequency of processor syscall u Pros u Halt a processor l Shared kernel space u Reset a processor l Good performance Kernel u Perform I/O operations u Cons (many things) l Instability: crash in any procedure • Other architectural support for protection in system? brings system down l Unweildy/difficult to maintain, extend 5 6 Layered Structure Possible Implementation: Protection Rings u Hiding information at each layer u Layered dependency Privileged instructions u Examples Level N can be executed only l THE (6 layers) . when current privileged • Mostly for functionality splitting . level (CPR) is 0 l MS-DOS (4 layers) Operating system u Pros Level 2 kernel l Layered abstraction Level 0 • Separation of concerns, elegance Level 1 Operating system Level 1 u Cons services l Inefficiency Hardware Level 2 l Inflexibility Applications Level 3 7 8 2 Microkernel Structure Virtual Machine u Services are regular processes u Virtual machine monitor u Micro-kernel obtains services for l Virtualize hardware users by messaging with services Apps Apps l Run several OSes u Examples: User OS OS . OS l Mach, Taos, L4, OS-X program Services l Examples 1 k • IBM VM/370 u Pros? VM1 VMk syscall l Flexibility to modify services • Java VM Virtual Machine Monitor l Fault isolation • VMWare, Xen u Cons? entry l Inefficient (boundary crossings) u What would you use µ-kernel l Inconvenient to share data virtual machine for? Raw Hardware between kernel and services l Just shifts the problem, to level with less protection? Testing? 9 10 Memory Protection The Big Picture u Kernel vs. user mode, plus u DRAM is fast, but relatively expensive u Virtual address spaces and Address Translation u Disk is inexpensive, but slow l 100X less expensive CPU Physical memory Abstraction: virtual memory l 100,000X longer latency No protection Every program isolated from all others and from the OS l 1000X less bandwidth Memory Limited size Illusion of “infinite” memory u Goals Sharing visible to programs Transparent --- can’t tell if l Run programs efficiently physical memory is shared l Make the system safe Disk Virtual addresses are translated to physical addresses 13 3 Issues Consider A Simple System u Many processes u Only physical memory l Applications use it directly l The more processes a system can handle, the better OS u Run three processes x9000 u Address space size l Email, browser, gcc l Many processes whose total size may exceed memory email u What if x7000 l Even one process may exceed physical memory size l browser writes at x7050? browser x5000 u Protection l email needs to expand? l A user process should not crash the system l browser needs more gcc x2500 l A user process should not do bad things to other memory than is on the Free processes machine? x0000 14 15 Need to Handle Handling Protection u Protection u Errors/malice in one process should not affect others u For each process, check each load and store u Finiteness instruction to allow only legal memory references l Not having entire application/data in memory at once gcc l Relocation address Physical CPU Check l Not having programmer worry about it (too much) memory error data 16 17 4 Handling Finiteness Virtual Memory u A process should be able to run regardless of physical u Flexible memory size or where its data are physically placed l Processes (and data) can move in memory as they u Give each process a large, static “fake” address execute, and can be part in memory and part on disk space that is large and contiguous and entirely its own u Simple u As a process runs, relocate or map each load and l Applications generate loads and stores to addresses in store to addresses in actual physical memory the contiguous, large, “fake” address space u Efficient email address Check & Physical l 20/80 rule: 20% of memory gets 80% of references CPU relocate memory l Keep the 20% in physical memory (a form of caching) u Protective data l Protection check integrated with translation mechanism 18 19 Address Mapping and Granularity Generic Address Translation: the MMU u Must have some “mapping” mechanism u CPU view l Map virtual to physical addresses in RAM or disk l Virtual addresses l Each process has its own CPU memory space [0, high] – u Mapping must have some granularity virtual address space Virtual address l Finer granularity provides more flexibility u Memory or I/O device view MMU l Finer granularity requires more mapping information l Physical addresses u Memory Management Unit Physical address (MMU) translates virtual address into physical address for each load and store Physical I/O memory device u Combination of hardware and (privileged) software controls the translation 20 21 5 Where to Keep Translation Information? Address Translation Methods Goals of translation u Base and Bound u Implicit translation for each Registers u Segmentation memory reference u A hit should be very fast u Paging L1 2-4x u Trigger an exception on a miss u Multilevel translation u Protect from user’s errors u Inverted page tables L2-L3 10-20x Memory 100-500x Paging 20M-30Mx Disk 22 Base and Bound Base and Bound (or Limit) Example: Cray-I u Protection l A process can only access physical virtual memory physical memory memory in [base, base+bound] bound 0 u On a context switch l Save/restore base, bound regs code 6250 (base) u Pros virtual address > l Simple error data l Inexpensive (Hardware cost: 2 registers, adder, comparator) + base u Cons bound l Can’t fit all processes in memory, have stack 6250+bound to swap physical address l Fragmentation in memory l Relocate processes when they grow? Each program loaded into contiguous l Compare and add on every instruction regions of physical memory. l Very coarse grained Example on next slide Why not have multiple contiguous segments for each process, and keep their base/bound data in hardware? 25 6 Segmentation Segmentation Example u Every process has table of (assume 2 bit segment ID, 12 bit segment offset) (seg, size) for its segments Virtual address v-segment # p-segment segment physical memory u Treats (seg, size) as a finer- segment offset > start size grained (base, bound) code (00) 0x4000 0x700 error 0 u Protection data (01) 0 0x500 seg size - (10) 0 0 l Every entry contains rights stack (11) 0x2000 0x1000 4ff u On a context switch . virtual memory l Save/restore table in kernel memory 2000 u Pros 0 l Programmer knows program and so 6ff segments, therefore can be efficient 2fff + 1000 l Easy to share data 14ff u Cons 4000 physical address 3000 l Complex management 46ff l Fragmentation 3fff 26 Segmentation Example (Cont’d) Segmentation u Pros l Provides logical protection: programmer “knows program” Virtual memory for strlen(x) physical memory for strlen(x) and therefore how to design and manage segments Main: 240 store 1108, r2 x: 108 a b c \0 l Therefore efficient 244 store pc+8, r31 … l Easy to share data 248 jump 360 24c Main: 4240 store 1108, r2 … 4244 store pc+8, r31 u Cons strlen: 360 loadbyte (r2), r3 4248 jump 360 l … 424c Complex management, programmer burden 420 jump (r31) … l Fragmentation strlen: 4360 loadbyte (r2), r3 … l Difficult to find the right granularity balance between ease of … use and efficiency x: 1108 a b c \0 4420 jump (r31) … … 29 7 Paging Paging example u Use a fixed size unit called page instead of segment Virtual address page table size virtual memory physical memory 0 u Use page table to translate VPage # offset 4 error a i u Various bits in each entry > b VP# PP# j u Context switch k Page table c 0 4 l l Similar to segmentation PPage# d 8 ... 1 3 u What should page size be? ... e 2 12 . 1 e u Pros . f f l Simple allocation PPage# ... g g h h l Easy to share 16 a page size: 4 bytes u Cons i b l Big table PPage # offset j c k d l PTEs even for big holes in Physical address memory l 30 How Many PTEs Do We Need? Segmentation with Paging u Assume 4KB page Virtual address l Needs “low order” 12 bits to address byte within page Vseg # VPage # offset u Worst case for 32-bit address machine l # of processes ´ 220 Page table 20 l 2 PTEs per page table (~4Mbytes), but there might be seg size PPage# ..