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

1. Exokernel: An Operating System Architecture for Application-Level Resource Management" by Dawson R. Engler, M. Frans Kaashoek, and James O'Toole Jr. Chris Franklin CS533 - Concepts of Operating Systems

2. Applications FIXED Abstractions Interface Hardware The Problem • Traditional operating systems fix the interface and implementation of OS abstractions.

3. Applications FIXED Abstractions Interface Hardware The Problem • Performance • Flexibility • Functionality

4. Apache SQL Server FIXED Abstractions Interface Hardware Example Traditional OS

5. Apache SQL Server Library OS Chosen from available Library OS Customized for SQLServer Abstractions Interface Abstractions Interface Example Exokernel – Application level resource management Exokernel Hardware

6. The Issues • Performance • Denies applications the advantages of domain-specific optimizations • Flexibility • Restricts the flexibility of application builders • Functionality • Discourages changes to the implementations of existing abstractions

7. Performance • There is no single way to abstract physical resources or to implement an abstraction that is best for all applications. • OS is forced to make trade-offs • Performance improvements of application-specific policies could be substantial

8. Flexibility • Fixed high-level abstractions hide informationfrom applications. • Makes it difficult or impossible for applications to implement their own resource management abstractions.

9. Functionality • Only one available interface between applications and hardware resources. • Because all applications must share one set of abstractions, changes to these abstractions occur rarely, if ever

10. The Solution • Separate protection from management • Allow user level to manage resources • Application libraries implement OS abstractions • Exokernel exports resources • Low level interface • Protects, does not manage • Expose hardware

11. End-to-End Argument • “if something has to be done by the user program itself, it is wasteful to do it in a lower level as well.” • Why should the OS do anything that the user program can do itself? • In other words - all an OS should do is securely allocate resources.

12. The Exokernel • A thin veneer that multiplexes and exports physical resources securely. • Simplicity allows efficiency • The lower the level of a primitive, the more efficiently it can be implemented, and the more latitude it grants to implementers of higher level abstractions.

13. The Exokernel • Resource management is restricted to • allocation, • revocation, • sharing • ownership tracking

14. Library operating systems • Use the low level exokernel interface • Higher level abstractions • Special purpose implementations An application can choose the library which best suits its needs, or even build its own.

15. Example Exokernel

16. Another Example

17. Design Challenge How can an Exokernel allow libOSes to freely manage physical resources while protecting them from each other?

18. Design Challenge How can an Exokernel allow libOSes to freely manage physical resources while protecting them from each other? • Track ownership of resources • Guard all resource usage • Revoke access to resources

19. Track ownership of resources Secure bindings – libOS can securely bind to machine resources

20. Secure Bindings • Exokernel allows libOSes to bind resources using secure bindings • Multiplex resources securely • Protection for mutually distrusted apps • Efficient

21. Secure Bindings • Secure Binding – a protection mechanism that decouples authorization from actual use of a resource • Allows the kernel to protect resources without having to understand them

22. Guard all resource usage Invisible resource revocation -Efficient – application layer not involved -Traditional OS Visible resource revocation -Allows libOS to guide deallocation and track availability of resources. -Exokernel

23. Revoke access to resources Abort protocol – Allows exokernel to break secure bindings of an uncooperative libOS by force

24. Conclusion • An Exokernel securely multiplexes available hardware raw hardware among applications • Application level library operating systems implement higher-level traditional OS abstractions • LibOSes can specialize an implementation to suit a particular application

25. Conclusion • The lower the level of a primitive… …the more efficiently it can be implemented … the more latitude it gives to higher level abstractions • So, separate management from protection and… …implement protection at a low level (exokernel) … implement management at a higher level (libOS)

26. References http://pdos.csail.mit.edu/exo.html http://c2.com/cgi/wiki?ExoKernel Modern Operating Systems – Andrew Tanenbaum http://computing.breinestorm.net/aegis+exception+ultrix+resource+exceptions/ http://128.138.224.40/csci5573-f03/lecture_notes/exokernel03_files/frame.htm http://pdos.csail.mit.edu/exo/exo-slides/ http://www.cs.ucf.edu/courses/cop5611/spring05/item/exokernel.pdf

27. Some Features • It is possible to have different libOSes, for example, one could export a Unix API and another a Windows API

28. Exokernel vs. Microkernel A micro-kernel provides abstractions to the hardware such as files, sockets, graphics etc. An exokernel provides almost raw access to the hardware.