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

1. Exokernel: An Opertion System Architecture for Application-Level Resource Management Dawson R. Engler, M. Frans Kaashoek, and James O’Toole Jr. MIT, Laboratory for Computer Science SIGCOMM ’96, PDOS-MIT Presented by Ahn Seunghoon

2. Motivation • Traditional OS has interface, that is the centralized resource manager • Applications run on the virtual machine • Fixed high-level abstraction • Low performance • Low flexibility • Low functionality • So Exokernel is designed

3. What is the Exokernel? • It includes an exokernel and untrusted (application-level) library OS • Exokernel defines low-level interface & multiplexes(not emulate but exports) available HW resources • Lib OS implements higher-level OS Application 1 Application 2 Library OS Secure binding TLBMemoryBFFDisk

4. Advantages of the architecture • Allows extension, specialization, and replacement of abstraction : High functionality & Flexibility • Conflict between the applications can be resolved without intervention of the kernel architects: High performance • Easy to implement : Simplicity • Easy to port : High portability & compatibility

5. Exokernel Design(1/3) • Exokernel separates protection from management through a low-level interface • Exokernel avoids resource management • Design principles • Securely expose hardware • Expose Allocation • Expose Names • Expose Revocation • Resource policy decision by library OS • Competing is allowed as traditional OS

6. Exokernel Design(2/3) • Secure Binding • Primary task that is protection mechanism decouples authorization • Simple operation • Authorization only at bind time(low management overhead) • No need to understand semantics at bind time • Needs set of primitives application can use to express protection check by H/W or S/W • H/W mechanism, S/W caching, Downloading application code

7. Exokernel Design(3/3) • Visible Resource Revocation • Higher latency but library OS can guide deallocation and have knowledge that resources are scarce • Frequent revoked modules can be invisible • The Abort protocol • When library OS fails to response quickly in fail state, secure binding must be broken by force • Using repossession vector

8. Experiment Environment • Two S/W • Aegis(Exokernel) & ExOS(Library OS) • Comparing to Ultrix4.2 • Mature monolithic UNIX OS • On MIPS-based DECstation

9. Aegis: an Exokernel(1/3) • Subsets of Aegis system call interfaces • Yield, Scall, Acall, Dealloc • Supports set of primitive operation that encapsulate privileged instructions • TLBBwr, FPUmod, CIDswitch, TLBvadelete • Aegis’s scheduling flexibility does not add overhead to base operation • Because Aegis does not use mapped DS, it does not have to separate kernel TLB misses from more general class of exceptions in its exception DEMUX routine -> Fast exceptions

10. Aegis: An Exokernel(2/3)

11. Aegis: An Exokernel(3/3)

12. ExOS: a library OS(1/3) • Manages fundamental OS abstraction at application level completely within the address space of the application that is using it • IPC Abstraction • Application-level Virtual Memory • Application-Specific Safe Handlers

13. ExOS: a library OS(2/3)

14. ExOS: a library OS(3/3)