Exokernel: An Operating System Architecture for Application-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, 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