201 likes | 369 Views
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?. Kernel space. User space. SP. Answer.
E N D
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? Kernel space User 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 • ….
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 user programs everything OS hardware
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 (1985-1994)
Microkernel structure illustrated user mode Firefox powerpoint user processes apache network file system system processes paging threads scheduling kernel communication processor control virtual memory microkernel protection hardware
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 • Entiresystem written for a type-safe runtime environment