CS 162 Spring 2004 Lecture 12 1/13 CS 162 Operating Systems and Systems Programming Professor: Anthony D. Joseph Spring 2004 Lecture 12: Protection: Kernel and Address Spaces 12.0 Main Points: • Kernel vs. user mode • What is an address space? • How is it implemented? Physical memory Abstraction: virtual memory No protection Limited size Sharing visible to programs Easy to share data between programs Each program isolated from all others and from the OS Illusion of infinite memory Transparent – can’t tell if memory is shared Ability to share code, data 12.1 Operating system organizations 12.1.1 Uniprogramming without protection Early personal computer operating systems: application always runs at the same place in physical memory, because each application runs one at a time (application given illusion of dedicated machine, by giving it reality of a dedicated machine). For example, load application into low memory, operating system into high memory. Application can address any physical memory location. CS 162 Spring 2004 Lecture 12 2/13 Application Operating System 0x000000 0xFFFFFF Physical Memory 12.1.2 Multiprogramming without protection: Linker-loader Can multiple programs share physical memory, without hardware translation? Yes: when a program is copied into memory, its addresses are changed (loads, stores, jumps) to use the addresses of where the program lands in memory. This is done by a linker-loader. Used to be very common. Application1 Operating System 0x00000 0xFFFFFF Physical Memory Application2 0x20000CS 162 Spring 2004 Lecture 12 3/13 UNIX ld does the linking portion of this (despite its name deriving from loading!): compiler generates each .o file with code that starts at location 0. How do you create an executable from this? Scan through each .o, changing addresses to point to where each module goes in larger program (requires help from compiler to say where all the relocatable addresses are stored). 12.1.3 Multiprogrammed OS with protection Goal of protection: • Keep user programs from crashing/corrupting OS • Keep user programs from crashing/corrupting each other How is protection implemented? Hardware support: • Address translation • Dual mode operation: kernel vs. user mode Hardware Machine-dependent OS layer Portable OS layer Application Application library User mode Kernel mode Typical Operating System Structure CS 162 Spring 2004 Lecture 12 4/13 12.2 Address translation Address space: literally, all the addresses a program can touch. All the state that a program can affect or be affected by. Restrict what a program can do by restricting what it can touch! Hardware translates every memory reference from virtual addresses to physical addresses; software sets up and manages the mapping in the translation box. CPU Translation Box (MMU) Physical Memory Virtual Address Physical Address Data read or write (untranslated) Address Translation in Modern Architectures Two views of memory: • View from the CPU – what program sees, virtual memory • View from memory – physical memory Translation box converts between the two views. Translation helps implement protection because there’s no way for programs to even talk about other programs’ addresses; no way for them to touch operating system code or data. Translation can be implemented in any number of ways – typically, by some form of table lookup (we’ll discuss various options for implementing the translation box later). Separate table for each user address space.CS 162 Spring 2004 Lecture 12 5/13 12.3 Dual mode operation Can application modify its own translation tables? If it could, could get access to all of physical memory. Has to be restricted somehow. Dual-mode operation • When in the OS, can do anything (kernel-mode) • When in a user program, restricted to only touching that program’s memory (user-mode) Hardware requires CPU to be in kernel-mode to modify address translation tables. In Nachos, as well as most OS’s: • OS runs in kernel mode (untranslated addresses) • User programs run in user mode (translated addresses) Want to isolate each address space so its behavior can’t do any harm, except to itself. A couple issues: 1. How to share CPU between kernel and user programs 2. How do programs interact? 3. How does one switch between kernel and user modes when the CPU gets shared between the OS and a user program? • OS -> user (kernel –> user mode) • User -> OS (user mode –> kernel mode) 12.3.1 Kernel -> user: To run a user program, create a thread to: • Allocate and initialize address space control block • Read program off disk and store in memory • Allocate and initialize translation table (point to program memory) • Run program (or to return to user level after calling the OS with a system call): • Set machine registers CS 162 Spring 2004 Lecture 12 6/13 • Set hardware pointer to translation table • Set processor status word (from kernel mode to user mode) • Jump to start of program 12.3.2 User-> kernel: How does the user program get back into the kernel? Voluntarily user->kernel: System call – special instruction to jump to a specific operating system handler. Just like doing a procedure call into the operating system kernel – program asks OS kernel, please do something on procedure’s behalf. Can the user program call any routine in the OS? No. Just specific ones the OS says are OK. Always start running handler at same place, otherwise, problems! How does OS know that system call arguments are as expected? It can’t – OS kernel has to check all arguments – otherwise, bug in user program can crash kernel. Involuntarily user->kernel: Hardware interrupt, also program exception Examples of program exceptions: • Bus error (bad address – e.g., unaligned access) • Segmentation fault (out of range address) • Page fault (important for providing illusion of infinite memory) On system call, interrupt, or exception: hardware atomically • Sets processor status to kernel mode • Changes execution stack to an OS kernel stack • Saves current program counter • Jumps to handler routine in OS kernel • Handler saves previous state of any registers it usesCS 162 Spring 2004 Lecture 12 7/13 Context switching between programs: same as with threads, except now also save and restore
View Full Document
Unlocking...