Operating Systems Engineering Based on MIT (2012, lec3) Recitation 2: OS Organization

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?

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

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

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

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 …

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

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 isolation in the kernel

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

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

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

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

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

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

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

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?

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

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

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

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