Download Operating System: A Software Engineering Perspective

Stack Management
Each process/thread has
two stacks
Kernel space
Kernel stack
User stack
Stack pointer changes
when exiting/entering the
kernel
Q: Why is this necessary?
SP
User space
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
System
Virtual
Memory
 Poor performance
 Each layer crossing has overhead associated with it
Hardware Abstraction Layer
An example of layering in
modern operating systems
Goal: separates hardwarespecific 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
powerpoint
processor
control
apache
file system
threads
network
scheduling
communication
microkernel
paging
kernel
system
processes
Firefox
user mode
user
processes
virtual
memory
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
Entire system written for a type-safe runtime
environment