Stack Management

Each process/thread has Kernel space

two stacks
Kernel stack
User stack SP

Stack pointer changes

User space
when exiting/entering the
kernel
Q: Why is this necessary?
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

user programs

OS everything

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

File Virtual
System Memory

 Poor performance
 Each layer crossing has overhead associated with it
 Hardware Abstraction Layer

An example of layering in

modern operating systems
Core OS
Goal: separates hardware- (file system,
specific routines from the scheduler,
system calls)
“core” OS Hardware Abstraction
Provides portability Layer
Improves readability (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 Firefox powerpoint

user mode
processes apache

file system network

system paging
processes threads scheduling

kernel
communication
microkernel virtual processor
memory protection control

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
Entire system written for a type-safe runtime
environment