1. Paper by Engler, Kaashoek, O’Toole Presentation by Charles Haiber

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

8.  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.  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.  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.  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.  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.  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.  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. 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.  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.  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.  Exokernel: An Operating System Architecture for Application-Level Resource Management 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 The Operating System Kernel as a Secure Programmable Machine Dawson R. Engler, M. Frans Kaashoek, and James O'Toole Jr., M.I.T. Laboratory for Computer Science  The case for application-specific operating systems. The case for application-specific operating systems. Thomas E. Anderson, Division of Computer Science, University of California at Berkeley