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
Top Related