1 / 20

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 , james} @ lcs.mit.edu. Exokernel: An Operating System Architecture for Application-Level Resource Management. Defining an OS.

sidone
Download Presentation

Exokernel: An Operating System Architecture for Application-Level Resource Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 Exokernel: An Operating System Architecture forApplication-Level Resource Management

  2. 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

  3. 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

  4. 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

  5. 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

  6. Example of Exokernel

  7. 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

  8. Exokernel Design • Goal: freedom to manage, protection from failure • Central Principle: securely expose hardware (avoid resource management) • Expose allocation • Expose names • Expose revocation

  9. 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

  10. 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

  11. 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

  12. But enough about Theory...Show me pictures!

  13. 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

  14. More pictures!!

  15. ExOS Implementation • OS abstractions at app level -within address space of app using it • IPC - • App-level Virtual Memory-

  16. Virtual memory operations

  17. ASH: Application-Specific Safe Handlers • Untrusted application-level message handlers downloaded into the kernel

  18. ExOS: Extensibility for Efficiency

  19. 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

  20. 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

More Related