exokernel an operating system architecture for application level resource management n.
Skip this Video
Loading SlideShow in 5 Seconds..
Exokernel: An Operating System Architecture for Application-Level Resource Management PowerPoint Presentation
Download Presentation
Exokernel: An Operating System Architecture for Application-Level Resource Management

Loading in 2 Seconds...

  share
play fullscreen
1 / 20
Download Presentation

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

sidone
110 Views
Download Presentation

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

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