Operating Systems Engineering

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