Exokernel: An Operating System Architecture forApplication-Level Resource Management

Dawson R. Engler, M. Frans Kaashoek, and James O’Toole Jr.M.I.T. Laboratory for Computer Science

Cambridge, MA 02139, U.S.A {engler, kaashoek, james}@lcs.mit.edu

Defining an OS Interface between applications and physical resources

Traditionally, machine resources are hidden in abstractions

Processes, files, address spaces, IPC, etc. Hard-coded – can't be replaced/modified

Bad design

applications denied domain-specific optimizations

discourages changes to abstractions restricts flexibility of application builders

Application-level Resource Management Abstractions implemented by untrusted software

Exokernel: a minimal kernel that exports resources via a low-level interface, up to a library OS

Goal: separate protection from management

Virtual machine for each application Heavy performance penalties

Exporting resources Techniques: secure binding, visible resource revocation,

abort protocol

Exokernel Implementation Aegis (exokernel) & ExOS (library OS)

Designed using 3 above techniques Efficiency of kernel (limited primitives) Efficiency at app. Level w/ flexibility Low overhead of secure multiplexing

Protected control transfer – 7x faster Exception dispatch – 5x faster

What's the Motivation? Past: Centralized management via abstractions

Implemented by privileged software No specialization, extensibility, replacement Cost: Overly General

Hurts application performance Hides information Limits functionality

Pro: End-to-End Argument

Example of Exokernel

Library OS Abstractions can be more specialized Not trusted by kernel – free to trust apps Mostly runs in user address space – fewer kernel

crossings Portable

Library interfaces & the Library OS itself Backwards compatibility

Exokernel Design Goal: freedom to manage, protection from failure Central Principle: securely expose hardware (avoid

resource management)

Expose allocation Expose names Expose revocation

Secure Bindings Protection mechanism to separate resource

authorization from usage Authorization at bind time, once A set of primitives used by apps for access checks 3 Methods to implement:

Hardware mechanisms Software caching Downloading application code

Visible Resource Revocation Taking back resources, breaking the bindings Traditionally invisible to application code

Faster Library OS has no knowledge of resource

scarcity Most exokernel revocations are visible

Visible naming requires it

Abort Protocol When a library OS fails to give up a resource

Already asked once nicely, again with time limit

Break existing secure bindings to the resource, inform the library OS

Small number of vital resources will not be repossessed

If they are, library receives an emergency exception

But enough about Theory...Show me pictures!

Aegis Implementation Processor is time sliced, by timer interrupts Processor environment stores resource event info Base cost for system calls and exceptions much lower

than Ultrix – Aegis doesn't map data structures All hardware exceptions (except system calls)

dispatched to applications - very efficient speeds Address Translation – guaranteed mappings Protected Control Transfer – sub-IPC mechanism Dynamic Packet Filter – creation of executable code at

runtime

More pictures!!

ExOS Implementation OS abstractions at app level -within address space of

app using it IPC -

App-level Virtual Memory-

Virtual memory operations

ASH: Application-Specific Safe Handlers Untrusted application-level message handlers

downloaded into the kernel

ExOS: Extensibility for Efficiency

Related Work Hydra: separate policy from mechanism VM/370: virtualize the base machine SPIN: extensions downloaded into kernel Cache Kernel: library OS focused on reliability

Conclusion Exokernel's simple, limited # of primitives can be

implemented efficiently Fast primitives means fast secure multiplexing Traditional abstractions can be efficient at app level Apps can create specific implementations of

abstractions by modifying a library

Therefore:Exokernel is good for extensibility and performance