Extensible Kernels
Mingsheng Hong
OS Kernel Types


Monolithic Kernels
Microkernels
–
–
–
–

Flexible (?)
Module Design
Reliable
Secure
Extensible Kernels
–
Can be customized (extended, specialized, replaced)


More functionality
Better performance
Motivations

Problems in traditional OS kernels
–
Implementation cannot be modified

–
LRU as general page replacement strategy
Hide information of machine resources

Not always appropriate in achieving high performance
–
–
database on top of file system
Provide a unified interface (overly general)

Trade-offs for different applications
–
page table structure
Approaches

Exokernel: safely expose machine resources
–
–
–

Higher-level abstractions are implemented in
applications
The concept of Library OS
Safety ensured by secure bindings
SPIN: use kernel extensions to safely
extend/change OS services/implementations
–
–
–
Event-driven model to customize services
Efficiency preserved
Safety ensured by PL facilities
Exokernel: Overview


An extension of RISC philosophy
Kernel provides minimum services
–
Hardware resource protection




–
Resource usage arbitration


Allocation
Revocation
Sharing
Tracking of ownership
Including an abort protocol
LibOS as powerful as traditional OS
Exokernel: OS Component Layout
Exokernel
A Motivating Example
*This example is borrowed from MIT website
The Reality …
If Exokernel is Used…
Exokernel: Design Principle

To separate protection from management
–

Can protect resources without understanding
them
When knowledge of resource is required
–
–
Can leave decisions to applications by
downloading code
Another level of indirection without sacrificing
performance
Exokernel: Secure Bindings

Why?
–

Library OSes are untrusted
How?
–
Hardware mechanism

–
Software caching

–
TLB entry
STLB
Downloading application code
Secure Bindings

Multiplexing physical memory
–
–
–
Records capabilities: ownership, R/W permissions
(authorization at bind time)
Checks capabilities(authentication at access time)
Enables resource sharing (How?)
Secure Bindings via Downloading
Code

Multiplexing the network
–
–
Uses Application-specific Safe Handlers (ASHs)
Performance


–
Eliminate kernel crossings
Decouple latency-critical operations from process
scheduling
Safety

Can be verified and trusted
More on ASHs

An ASH can serve as a
–
–
Packet filter
Computation unit

–
–
checksumming
Message initiator
Control initiator
Issues in Resource Revocation

Visible deallocation of resource
–
So that library OS has a chance to react

–
But could be less efficient



Can combine invisible revocation
Library OS can be prepared for such occasions
But when application does not cooperate…
–
Abort Protocol – imperative revocation


e.g. when physical page “5” is deallocated
e.g. cpu time slice
Need to leave some resource for each libOS
–
Guaranteed mapping
Experiment: Aegis & ExOS

Aegis: an exokernel on MIPS-based
DECstation
–

ExOS: the corresponding library OS
–
–

Xok: another exokernel for Intel x86 computers
Virtual memory, IPC are managed at application
level
Can be extended
Performance compared with: Ultrix
Procedure and System Calls
Protected Control Transfers

Suggested reasons (?)
–
–
Kernal crossing
TLB flush
ExOS: IPC, VM
ASH: Scalability
Conclusion

Securely multiplexes hardware resources, to
achieve more flexibility & efficiency
–
–
–
OS primitives
High level abstractions: VM, IPC
Implementation can be customized (libOS)
Some Issues

Exokernel
–

Portability
Library OS
–
–
Too much code in user space?
Not easy to customize?

–
–
OSKit, SPIN
Should provide a standard interface?
Security
SPIN: an Extensible OS

Uses language features to make a system
–
Extensible

–
Safe

–
Type safe language
Efficient


Dynamic linking & later binding
In kernel space
Modula-3 features: memory safe; interfaces
Traditional OSes
*This picture is borrowed from Univ. of Washington website
SPIN Structure
*This picture is borrowed from Univ. of Washington website
The Protection Model

Pointers as capabilities
–
–
–

Types not forgeable
Determined at compile-time => efficient
Externalized when passed across domains
An object is safe if
–
–
Verified by the compiler
Or asserted so by the kernel (objected
implemented in other languages)
The Extension Model

Events and handlers
handlers
predicates
P1
P2
P3
event
Execution of handlers can be
•Synchronous/ asynchronous
•Bounded in time
•Ordered/unordered
Core Services



Services that cannot be safely implemented
by extensions
Simple functionality
Fine grained control
Core Services: Memory Management

Manage memory and processor resources
–
MM interfaces



Storage: allocate, deallocate, reclaim
Naming : allocate, deallocate
Translation: add/remove/examine mapping
–
–
Exceptions
 PageNotPresent
 BadAddress
 ProtectionFault
Address space model can be defined on top of the
primitives
Core Services: Thread Management

Thread Management
–
Strand interface


–
–

block/unblock
checkpoint/resume
Global and application-specific schedulers
Thread model can be defined on top of the
primitives
Core services are trusted
–
Extensions should be fault-isolated
Performance I: Competitors



DEC OSF/1: monolithic kernel
Mach 3.0: microkernel
SPIN: extensible kernel
Performance II: Microbenchmarks
IPC
Thread management
VM primitives
•Kernel crossings
•Overhead in demultiplexing exception (?)
Performance III: Networking
Latency and bandwidth
Packet forwarding
End-to-End Performance
Networked Video System
A dilemma in web server buffer management
-- hybrid cache policy
Issues in SPIN


Scalability of the event/handler model
How to prioritize handlers?
–

Throughput vs. fairness
Extensibility limited by interfaces
Conclusion


Two methods to make OS more flexible &
efficient
Both reduce kernel crossings
–
–
Exokernel: libOS
SPIN: link extension code to kernel space