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

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 1Application 2 Secure binding TLB Memory BFF Disk Library OS

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) MachineOSProcedure Call Syscall DEC2100Ultrix0.5732.2 DEC2100Aegis0.563.2/4/7 DEC3100Ultrix0.4233.7 DEC3100Aegis0.422.9/3.5 DEC5000Ultrix0.2821.3 DEC5000Aegis0.281.6/2.3

11. Aegis: An Exokernel(3/3) MachineOSunalignoverflowcoprocprot DEC2100Ultrix n/a208.0n/a 238.0 DEC2100Aegis 2.8 3.0 DEC3100Ultrix n/a151.0n/a 177.0 DEC3100Aegis 2.1 2.3 DEC5000Ultrix n/a130.3n/a 154.0 DEC5000Aegis 1.5

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) MachineOSpipepipe ’ shmLrpc DEC2100Ultrix326.0n/a187.0n/a DEC2100Aegis30.924.812.413.9 DEC3100Ultrix243.0n/a139.0n/a DEC3100Aegis22.618.69.310.4 DEC5000Ultrix199.0n/a118.0n/a DEC5000Aegis14.210.75.76.3 MachineOSdirtyProt1Prot100unprot100TrapAppel1Appel2 DEC2100Ultrixn/a51.6175.0 240.0383.0335.0 DEC2100Aegis24.832.5213.0275.013.974.445.9 DEC3100Ultrixn/a39.0133.0 185.0302.0267.0 DEC3100Aegis18.624.4156.0206.010.155.034.0 DEC5000Ultrixn/a32.0102.0 161.0262.0232.0 DEC5000Aegis10.716.9143.0 4.834.022.0

14. ExOS: a library OS(3/3) MachineOSRoundtrip latency DEC5000 /125 ExOS/ ASH 259 DEC5000 /125 ExOS320 DEC5000 /125 Ultrix3400 DEC5000 /200 Ultrix/ FRPC 340