Operating Systems Engineering

Based on MIT 6.828 (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