1 / 18

Exokernels as an alternative to Traditional Operating Systems

Exokernels as an alternative to Traditional Operating Systems. Paper by Engler, Kaashoek, O’Toole Presentation by Charles Haiber. Contents. Exokernels Overview vs. traditional kernels Library Operating Systems Design Principals Secure Bindings Visible Resource Revocation Abort Protocol

rania
Télécharger la présentation

Exokernels as an alternative to Traditional Operating Systems

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. Exokernels as an alternative to Traditional Operating Systems Paper by Engler, Kaashoek, O’Toole Presentation by Charles Haiber

  2. Contents • Exokernels • Overview vs. traditional kernels • Library Operating Systems • Design Principals • Secure Bindings • Visible Resource Revocation • Abort Protocol • Testing • Hypothesizes • Results/Conclusion • Is it secure?

  3. Exokernels • The main goal of an exokernel: • The separation of protection from management • Instead of emulating hardware resources, it exports them directly to the applications • In addition to the exokernel, a “Library OS” can act as an abstraction layer between hardware and application

  4. Exokernels vs. Traditional Kernels • Fixed, high-level abstractions, provided by kernels to enable as many types of applications to run on the system, tend to have a very high cost in system resources • Hurts the performance of applications • Hides information from applications • Limits the functionality of applications

  5. Exokernels vs. Traditional Kernels Exokernels exist as a thin layer on top of the hardware that multiplexes and exports physical resources securely The idea is that an application will better know how it wants to manage it’s resources than a monolithic kernel or microkernel

  6. Exokernel’s Library OS • Multiple Library Operating Systems can exist • Exist to provide specialized abstractions • One OS might cater specifically to networking • Library OS are not trusted by the exokernel • They are free to trust the applications • They run on the application level themselves • Allow applications to be ran on any hardware

  7. Exokernel Diagram

  8. Exokernel Design Principals • Securely expose hardware • Avoid hardware management, except when required for the protection of the system • Expose allocation to Library OS • Expose names of physical resources • Expose revocation protocol

  9. Techniques of Secure Exportation • Secure Bindings • Allows applications to securely bind themselves to resources • Visible Resource Revocation • Applications participate in a resource revocation protocol • Abort Protocol • The exokernel can forcibly break secure bindings of uncooperative applications

  10. Secure Bindings • Protection mechanism that separates authorization from the use of a resource • Authorization only checked at bind time • Applications responsible for resources with complex hardware semantics (networks, file systems, etc.) • This frees up the exokernel to perform access checks at access time • Allows the kernel to protect hardware resources without needing to understand them

  11. Visible Resource Revocation Traditionally, resource revocation is invisible to applications in monolithic and micro-kernels By exposing resource revocation, the exokernel allows applications and Library OSs to monitor resource usage and act accordingly

  12. Abort Protocol • Allows the exokernel to retrieve resources from a Library OS that is not responding to revocation requests • Revocation request – “Please return a memory page” • Revocation imperative – “Return a memory page within 50 microseconds” • Secure binding is broken, and the Library OS sent a repossession exception

  13. Exokernel Testing • Aegis – an experimental exokernel • Exports the processor, physical memory, exceptions, interrupts, and network resources • ExOS – an experimental Library OS • Provides processes, virtual memory, user-level exceptions, interprocess abstractions, and several network protocols • Ultrix is a mature monolithic Unix-based OS

  14. Hypothesizes Exokernels are very efficient Low-level, secure multiplexing can be efficient Traditional OS abstractions can be implemented efficiently at application level Applications can create special-purpose implementations of these abstractions

  15. Results vs. Ultrix • Both Aegis and Ultrix ran on the same hardware • No overhead added to procedure calls • Exception dispatch about 100x faster in Aegis • ExOS’s implementation of pipes about 100x faster

  16. Conclusion to Testing All four hypothesizes were proven to be correct when compared to Ultrix Results show that the exokernel design is well suited as a high-performance, extensible OS. Additionally, previous research found that applications benefit greatly from specialized abstractions, and ExOS backed those conclusions up as well

  17. Is it secure? • Total mediation: NO • OS does very little resource management and only authorizes resource usage at bind time • Trustworthy: YES • Only the exokernel is part of the TCB, with the Library OSs being ran at application level • Verifiable: YES • Kernel is extremely small, with only two goals: • Present hardware resources • Do so securely

  18. References • 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 • The Operating System Kernel as a Secure Programmable Machine • Dawson R. Engler, M. FransKaashoek, and James O'Toole Jr., M.I.T. Laboratory for Computer Science • The case for application-specific operating systems. • Thomas E. Anderson, Division of Computer Science, University of California at Berkeley

More Related