1 Operating Systems and Protection Professor Jennifer Rexford CS 217

2 Goals of Today’s Lecture Boundary between parts of the system  User programs  Operating system  Computer hardware How multiple programs can run at once  Context switching to share the CPU  Paging from disk to share the physical memory Underlying data structures and mechanisms  Process Control Block (PCB)  Virtual memory and paging

3 Operating System Supports virtual machines  Promises each process the illusion of having whole machine to itself Provides services:  Protection  Scheduling  Memory management  File systems  Synchronization  etc. Hardware Operating System User Process User Process

4 What is a Process? A process is a running program with its own …  Processor state –EIP, EFLAGS, registers  Address space (memory) –Text, bss, data, heap, stack Supporting the abstraction  Processor –Saving state per process –Context switching  Main memory –Sharing physical memory –Supporting virtual memory  Efficiency, fairness, protection Hardware Operating System User Process User Process

5 Divide Hardware into Little Pieces? Idea: registers, memory, ALU, etc. per process  Pro: totally independent operation of each process  Con: lots of extra hardware; some parts idle at any given time; hard limit on the number of processes Operating System User Process User Process Hardware

6 Indirection, and Sharing in Time? Idea: swap processes in and out of the CPU; map references into physical addresses  Pro: make effective use of the resources by sharing  Con: overhead of swapping processes; overhead of mapping memory references Hardware Operating System User Process User Process

7 Sharing the CPU Across Processes

8 When to Change Which Process is Running? When a process is stalled waiting for I/O  Better utilize the CPU, e.g., while waiting for disk access When a process has been running for a while  Sharing on a fine time scale to give each process the illusion of running on its own machine  Trade-off efficiency for a finer granularity of fairness CPU I/O 1: CPU I/O 2:

9 Life Cycle of a Process Running: instructions are being executed Waiting: waiting for some event (e.g., I/O finish) Ready: ready to be assigned to a processor CreateReadyRunningTermination Waiting

10 Switching Between Processes Context  State the OS needs to restart a preempted process Context switch  Saving the context of current process  Restoring the saved context of some previously preempted process  Passing control to this newly restored process Running Save context Load context Save context Load context RunningWaiting Process 1 Process 2

11 Context: What the OS Needs to Save Process state  New, ready, waiting, halted CPU registers  EIP, EFLAGS, EAX, EBX, … I/O status information  Open files, I/O requests, … Memory management information  Page tables Accounting information  Time limits, group ID,... CPU scheduling information  Priority, queues

12 Process Control Block (PCB) For each process, the OS keeps track of...  Process state  CPU registers  CPU scheduling information  Memory management information  Accounting information  I/O status information ready EIP EFLAGS EAX EBX... etc. PCB3 PCB2 PCB1 OS’s memory Process 1’s memory Process 2’s memory Process 3’s memory

13 Separate Address Space Per Process

14 Sharing Memory In the old days…  MS-DOS (1990)  Original Apple Macintosh (1984) Problem: protection  What prevents process 1 from reading or writing process 3’s memory?  What prevents process 2 from reading or writing OS’s memory? Solution: Virtual Memory protection  IBM VM-370 (1970)  UNIX (1975)  MS Windows (2000) PCB3 PCB2 PCB1 OS’s memory Process 1’s memory Process 2’s memory Process 3’s memory

15 Virtual Memory Give each process its own address space  Large: 4 GB of memory with 32-bit addresses  Uniform: contiguous memory locations, from 0 to  Protected: prevent other processes from reading/writing Realizing the abstraction  Associate the address space with the disk –Store the address space of each process  Use main memory as a cache for the disk –Swap data back and forth between disk and memory One of the great ideas in computer systems!

16 Disk vs. Main Memory Main memory  Relatively fast  Random access  Modest capacity (e.g., 512 MB) Disk  Slow (100,000 times slower)  Seek time to read first byte  High capacity (e.g., 200 GB) Goal: performance of memory, with the capacity of disk

17 Making Good Use of Memory and Disk Good use of the disk  Read and write data in large “pages”  … to amortize the cost of “seeking” on the disk  E.g., page size of 4 KB Good use of main memory  Even though the address space is large  … programs usually access only small portions at a time  Keep the “working set” in main memory –Demand paging: only bring in a page when needed –Page replacement: selecting good page to swap out Goal: avoid thrashing  Continually swapping between memory and disk

18 Uniquely Identifying an Address Process identifier  Indicates which process is performing the access  Process ID register stores identifier of running process Virtual page number  Number of the page in the virtual address space  Extracted from the upper bits of the (virtual) address  … and then mapped to a physical page number Offset in a page  Number of the byte within the page  Extracted from the lower bits of the (virtual) address  … and then used as offset from start of physical page

19 Virtual Memory for a Process Virtual Address SpacePhysical Address Space address 0 virtual page number offset in page physical page number offset in page Translate virtual page number to physical page number 32 bits

20 Sharing Physical Memory Process 2 Virtual Address Space Physical Address Space 0 1 Process 1 Virtual Address Space OS V.A.S. 0 1

21 Maintaining Page Tables Process 1 Virtual Address Space Physical Address Space 0 1 Process 2 Virtual Address Space Process Number OS V.A.S.

22 Page Tables in Memory... Process 1 Virtual Address Space Physical Address Space 0 1 Process 2 Virtual Address Space OS V.A.S.

23 Process ID Register Physical Address Space Process Process ID address virtual page number offset in page

24 Protection Between Processes Process Process ID address virtual page number offset in page User-mode (unprivileged) process cannot modify Process ID register If page tables are set up correctly, process #1 can access only its own pages in physical memory The operating system sets up the page tables

25 Running Out of Physical Memory Physical memory often smaller than virtual memory  E.g., 256 MB of RAM, compared to 4 GB Physical memory shared by many processes  Where each process has up to 4 GB of virtual memory Want the abstraction of 4 GB memory per process  Even though the actual memory is smaller Fortunately, the disk is typically much larger  Can “swap” pages to and from the disk  Treating main memory as a “cache” of the disk

26 Paging Process xx Process ID address virtual page number offset in page Physical Address Space

27 Page Fault! Process xx Process ID Physical Address Space movl , %eax

28 Write Some Other Page to Disk Process yy 2 xx Process ID Physical Address Space movl , %eax 2

29 Fetch Current Page, Adjust Page Tables Process yy Process ID Physical Address Space movl , %eax

30 Measuring the Memory Usage % ps l F UID PID PPID PRI VSZ RSS STAT TIME COMMAND SN 0:00 -csh SN 5:52 emacs RN 0:00 ps l Virtual memory usage Physical memory usage (“resident set size”) CPU time used by this process so far Unix Windows

31 Mechanics of Page Faults

32 Context Switch, in More Detail Running Save context Load context Save context Load context RunningWaiting Process 1 Process 2

33 Context Switch, in More Detail Running Waiting Process 1 addl %eax, %ecx movl –8(%ebp), %eax addl %eax, %ecx. page fault PCB3 PCB2 PCB1 OS’s memory Process 1’s memory Registers

34 Hardware: Trigger Page-Fault Code Fault-handler hardware  Recognizes the page “miss”  Triggers OS code to handle the page fault Enters privileged mode  So, OS can manipulate the necessary data structures Prepares for later return to the user process  Pushes old (process 1) EIP and ESP on OS stack Prepares to run the OS code  Sets EIP to specific location in operating system  Sets ESP to operating-system stack in OS memory

35 Operating System: Context Switch Handles the old process 1  Saves registers in Process Control Block #1 –Pops saved EIP and ESP registers from its own stack –Copies the rest of the registers into PCB1  Sends instructions to disk drive to fetch page –Puts process #1 in “waiting” state Prepares for the new process 2 to run  Sets process-ID register to 2  Restores registers from Process Control Block #2 –Pushes saved EIP and ESP registers onto OS stack –Copies the rest of the saved registers from PCB2  Executes “return from interrupt” instruction

36 Hardware: Starts New Process Restores the EIP and ESP registers  Pops process #2’s registers from the OS stack Switches back to unprivileged mode  So process #2 runs as a user process Resumes where process #2 left off last time  With all of its context restored

37 System call, just another kind of fault Running Waiting Process 1 mov $4,%eax int $0x80 addl %eax, %ecx. system call (privileged instruction) PCB3 PCB2 PCB1 OS’s memory Process 1’s memory Registers

38 Summary Abstraction of a “process”  CPU: a share of CPU resources on a small time scale  Memory: a complete address space of your own OS support for the process abstraction  CPU: context switch between processes  Memory: virtual memory (VM) and page replacement  Files: open/read/write, rather than “move disk head”  Protection: ensure process access only its own resources Hardware support for the process abstraction  Context switches, and push/pop registers on the stack  Switch between privileged and unprivileged modes  Map VM address and process ID to physical memory