1 / 20

Operating Systems Engineering

Operating Systems Engineering. Recitation 2: OS Organization. Based on MIT 6.828 (2012, lec3). Overall OS Design. Two major aspects: What should the main components be? What should the interfaces look like? To answer that, we need to ask: Why have an OS at all? Why not a library?.

fayola
Télécharger la présentation

Operating Systems Engineering

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 Systems Engineering Recitation 2: OS Organization Based on MIT 6.828 (2012, lec3)

  2. Overall OS Design • Two major aspects: • What should the main components be? • What should the interfaces look like? • To answer that, we need to ask: • Why have an OS at all? • Why not a library?

  3. OS Requirements • One key requirement: • Support for multiple activities • Concurrent or at least Pseudo-Concurrent • Which requires: • Resource multiplexing • Activity isolation • Interaction between activities

  4. Overall OS Design • Helpful approach – use abstractions • Disk  File system • Network card  Sockets • CPU and Memory  Processes • Not all OS designs are created equal

  5. Focus on xv6 • An educational OS based on UNIX V6 • only a few abstractions \ services • Processes • File system • I/O (via file descriptors)

  6. xv6 – Processes • A process is a running program • A process can have: • A Share of the CPU • Private memory • File descriptors • Parent process • Child processes • …

  7. xv6 – Processes • Uses resources through kernel services • File system • Memory allocations • Interaction with other processes • … • Kernel is contacted via system calls • Very traditional design

  8. xv6 – A Monolithic Kernel • Kernel is a big program • Contains all services, low level hardware mechanisms • Entire kernel runs with full privileges • Good side – easy subsystem interactions • Bad sides – • complex interactions  bugs • no isolationin the kernel

  9. Sidestep – Kernel Types • A monolithic kernel is but one option • What has to be in the kernel? • Could FS be a user library? • Why? Why not? • There are models for smaller kernels • Microkernel • Exokernel • Nonkernel

  10. Isolation • The most constraining requirement • Determines much of the base design • xv6’s unit of isolation – a process

  11. xv6 – Process Isolation • Prevent process X from spying on Y • Prevent process X from corrupting Y • Separated memory, file descriptors • Prevent resource exhaustion (fairness) • Protect kernel from processes • Defensive tactic • Against buggy programs • Against malicious programs

  12. xv6 – Isolation Mechanisms • User/Kernel mode flag • System call abstraction • Address spaces • Timeslicing

  13. User/Kernel Mode Flag • Called CPL in x86 • Bottom two bits of the cs register • CPL=0 – kernel mode – privileged • CPL=3 – user mode – not privileged cs: CPL

  14. User/Kernel Mode Flag • CPL is the base to almost every isolation • Writes to control registers (cs, for instance) • Writes to certain flags • Memory access • I/O Port access • However, setting CPL=3 is not enough • Kernel needs to manage policy

  15. System calls • Call from user to kernel – needs to change CPL • Can this be done? • set CPL=0 • jmpsys_open User defined! • How about a combined instruction that forces the user to jump to a kernel address?

  16. System calls - x86 solution • Kernel sets allowed entry points • int instruction sets CPL=0 and jumps • Saves the values of cs and eip on stack • System call returns with iret • Restores old cs and eip • Should these instructions be privileged?

  17. Address spaces • How can we isolate process memory? • Use of x86 paging hardware • MMU maps addresses: virtual to physical • On instruction fetchs • On data load and store • No direct access to physical addresses

  18. x86 Page Tables • Basically, an array of entries, each maps a 4KB range of “virtual” addresses • Each such 4KB region is a page • Kernel switches page tables when switching processes • Supervisor bit protects kernel

  19. Hardware Support for Isolation • Q: Can you have process isolation without HW support for kernel mode? • A: Yes, but using HW support is relatively easy and the most popular approach

  20. Timeslicing • Still need to isolate the CPU • Processes might be uncooperative • Non-yielding infinite loop • HW provides a periodic clock interrupt • Same mechanism as system calls • Enables preemptive context switching • Kernel needs to save state – seamless to processes • Has its problems, but extremely popular

More Related