Embed Size (px)
Citation preview
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 StructureAndrew 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 concurrencyBackwards 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
FileSystem
VirtualMemory
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 AbstractionLayer
(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
hardware
microkernel
system processes
user processes
virtual memory
communication
protection
processor control
file system
threads
network
schedulingpaging
Firefox powerpoint
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
