Stack Management Each process/thread has two stacks  Kernel stack  User stack Stack pointer changes when exiting/entering the kernel Q: Why is this necessary? User space Kernel space SP

Answer The user stack pointer is under the control of the (untrusted) application. A buggy or malicious application could set the stack pointer to a bogus value  For example, a nonexistent address or an address inside the kernel

Alternate Answer In a multi-threaded environment, thread A can modify thread B’s stack (they reside in the same address space).  Thus, thread A could change thread B’s control flow inside the OS Modifying arguments Changing return values etc.

Operating System Structure Andrew Whitaker CSE451

Operating System Structure Goal: Arrange OS software components to maximize:  Reliability  Security  Readability  Extensibility  Performance  ….

Motivation: OS Projects Gone Awry

What Is Writing an OS So Difficult? Complexity  Millions of source code lines  Thousands of developers and testers Unforgiving programming environment  OS runs on the raw hardware  A bug crashes the whole machine Interrupts and concurrency Backwards compatibility constraints

The Simplest Approach: Monolithic Kernels Traditionally, OS’s are built as a monolithic entity:  Single linked binary  Any function can call any other function everything user programs hardware OS

Monolithic design Major advantage:  cost of module interactions is low (procedure call) Disadvantages:  As system scales, it becomes: Hard to understand Hard to modify Hard to maintain  Unreliable (no isolation between system modules) What is the alternative?  Find a way to organize the OS in order to simplify its design and implementation

Layering Idea: Implement OS as a set of layers The first description of this approach was Dijkstra’s THE system (1968!)  Layer 5: Job Managers Execute users’ programs  Layer 4: Device Managers Handle devices and provide buffering  Layer 3: Console Manager Implements virtual consoles  Layer 2: Page Manager Implements virtual memories for each process  Layer 1: Kernel Implements a virtual processor for each process  Layer 0: Hardware Each layer can be tested and verified independently

Problems with Layering Strict hierarchical structure is too inflexible  Real systems have “uses” cycles File system requires virtual memory services (buffers) Virtual memory would like to use files for its backing store Poor performance  Each layer crossing has overhead associated with it File System Virtual Memory

Hardware Abstraction Layer An example of layering in modern operating systems Goal: separates hardware- specific routines from the “core” OS  Provides portability  Improves readability Core OS (file system, scheduler, system calls) Hardware Abstraction Layer (device drivers, assembly routines)

Microkernels Philosophy  Strict hierarchy is bad  But, modularity is good Design:  Minimize what goes in kernel  Organize rest of OS as user-level processes e.g., file system “server”  Processes communicate using message-passing Like a distributed system Examples  Hydra (1970s)  Mach ( )

Microkernel structure illustrated hardware microkernel system processes user processes virtual memory communication protection processor control file system threads network scheduling paging Firefoxpowerpoint apache user mode kernel

Microkernels: Pros and Cons Pros  Simplicity Core kernel is very small  Extensibility Can add new functionality in user-mode code  Reliability OS services confined to user-mode programs Cons  Poor performance Message transfer operations instead of system call

State of the Art: Kernel Modules Basic idea: users can supply modules, which run directly in the kernel’s address space Pros:  Good performance  Extensibility Cons:  Modules can compromise security, reliability Device drivers cause 85% of crashes in Windows 2000!

Safe Languages in the OS UW’s SPIN Operating System  All kernel extensions written in a type-safe language Fast and safe MSR’s Singularity Project  Entire system written for a type-safe runtime environment