1 / 38

Operating Systems and Protection

Operating Systems and Protection. Professor Jennifer Rexford CS 217. 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

vivian-wilkerson
Download Presentation

Operating Systems and Protection

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Operating Systemsand 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. User Process User Process Operating System Hardware

  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 User Process User Process Operating System Hardware

  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 User Process User Process Operating System Hardware

  6. User Process User Process Operating System Hardware 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

  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 CPU I/O CPU I/O 1: CPU I/O CPU I/O 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 Create Ready Running Termination Waiting

  10. Process 2 Process 1 Waiting Running Save context . . . Load context Waiting Running Save context . . . Load context Waiting Running 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

  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. PCB1 PCB2 PCB3 Process 1’s memory Process 2’s memory Process 3’s memory OS’s memory

  13. Separate Address Space Per Process

  14. Process 3’s memory Process 1’s memory 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) Process 2’s memory PCB1 PCB2 PCB3 OS’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 232-1 • 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. 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) Disk vs. Main Memory 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 Translate virtual page number to physical page number 32 bits address offset in page offset in page virtual page number physical page number 0 Virtual Address Space Physical Address Space

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

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

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

  23. Process ID Register 1 6 3 0 2 2 5 5 0 1 1 2 4 4 1 2 0 0 6 3 0 1 Process 2 2 Process ID 2 1 1 address 0 offset in page 0 virtual page number Physical Address Space

  24. Protection Between Processes 3 2 2 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 5 1 1 2 4 1 0 0 6 0 Process 2 Process ID 2 address offset in page virtual page number

  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 3 2 2 xx 1 1 2 4 1 2 0 0 6 3 0 1 Process 2 2 Process ID 2 1 1 address 0 offset in page 0 virtual page number Physical Address Space

  27. Page Fault! 3 2 2 xx 1 1 2 4 1 2 0 0 6 3 0 1 Process 2 2 Process ID 2 1 1 0 movl 0002104, %eax 0 Physical Address Space

  28. Write Some Other Page to Disk yy 2 2 xx 2 1 1 2 4 1 0 0 6 3 0 1 Process 2 2 Process ID 2 1 1 0 movl0002104, %eax 0 Physical Address Space

  29. Fetch Current Page, Adjust Page Tables yy 2 2 3 1 1 2 4 1 0 0 0 6 3 0 1 Process 2 2 Process ID 2 1 1 0 movl0002104, %eax 0 Physical Address Space

  30. Measuring the Memory Usage Virtual memory usage Physical memory usage (“resident set size”) CPU time used by this process so far % ps l F UID PID PPID PRI VSZ RSS STAT TIME COMMAND 0 115 7264 7262 17 4716 1400 SN 0:00 -csh 0 115 7290 7264 17 15380 10940 SN 5:52 emacs 0 115 3283 7264 23 2864 812 RN 0:00 ps l Unix Windows

  31. Mechanics of Page Faults

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

  33. Process 1’s memory Context Switch, in More Detail Process 1 page fault Running addl %eax, %ecx movl –8(%ebp), %eax addl %eax, %ecx . . . Waiting PCB1 PCB2 PCB3 Running OS’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. Process 1’s memory System call, just another kind of fault Process 1 system call (privileged instruction) Running mov $4,%eax int $0x80 addl %eax, %ecx . . . Waiting PCB1 PCB2 PCB3 Running OS’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

More Related