1. Exokernel: An Operating System Architecture for Application-Level Resource Management by Dawson R. Engler, M. Frans Kaashoek, and James O'Toole Jr. Presented By Md Atiqur Rahman

2. Traditional operating systems Fixed interface and implementation of OS abstractions. FIXED Hardware Applications InterfaceAbstractions

3. The Issues Performance ◦ Denies applications the advantages of domain- specific optimizations ◦ No single way to abstract physical resources or to implement an abstraction that is best for all applications.

4. The Issues Flexibility ◦ Restricts the flexibility of application builders ◦ Fixed high-level abstractions hide information from applications. ◦ Difficult or impossible for applications to implement their own resource management abstractions.

5. The Issues Functionality ◦ Discourages changes to the implementations of existing abstractions ◦ 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

6. The Solution End-to-End Argument ◦ Applications know better than OS what the goal of their resource management decisions should be Application level resource management Separate protection from management

7. Exokernel *Taken from Wikipedia

8. Exokernel A thin veneer that multiplexes and exports physical resources securely. Lower the level of a primitive.

9. Exokernel Resource management Track ownership and ensure protection Secure binding Revoke access Visible revocation Abort protocol

10. 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. Portable

11. Exokernel-Design Principle Securely expose hardware Kernel should provide secure low-level primitives that allow all hardware resources to be accessed as directly as possible. Expose allocation Allow to request specific physical resources Expose Names Export physical names. Remove a level of indirection: Translation Expose Revocation Utilize a visible resource revocation protocol

12. Secure Bindings Exokernel allows libOSes to bind resources using secure bindings. Decouples authorization from the actual use of a resource. Multiplex resources securely Performs authorization only at bind time. ◦ Allows the kernel to protect resources without having to understand them

13. Secure Bindings Three basic techniques ◦ Hardware mechanisms  Appropriate hardware support allows secure bindings to be couched as low-level protection operations. ◦ Software caching  Secure bindings can be cached in an Exokernel. ◦ Downloading application code.

14. Secure Bindings-Example Multiplexing Physical Memory Using self-authenticating capability and address translation hardware To ensure protection: guards access by requiring to present the capability To break: change capability and free resource Multiplexing the Network A software support is provided by packet filters Application code, filters, is downloaded into kernel

15. Secure Bindings-Downloading code Advantages: ◦ Elimination of kernel crossings. ◦ Can be executed in situations where context switching to the application itself is infeasible. Optimization: ◦ High-level languages provides more information for optimization.

16. Secure Bindings-Visible Resource Revocation Invisible resource revocation ◦ Efficient – application layer not involved ◦ Library operating systems cannot guide deallocation. Visible resource revocation ◦ Allows libOS to guide deallocation and track availability of resources.

17. Secure Bindings-The Abort Protocol Take resources from library operating systems by force. Possible ways ◦ Kill any library operating system and its associated application ◦ Breaks all existing secure bindings.  Repossession vector.

18. Status and Experimental Methodology Aegis: an exokernel. ExOS: a library operating system. Experiments test four hypotheses: ◦ Exokemels can be very efficient, ◦ Low-level, secure multiplexing of hardware resources can be implemented efficiently. ◦ Traditional operating system abstractions can be implemented efficiently at application level. ◦ Applications can create special-purpose implementations of these abstractions.

19. Experimental platforms.

20. Aegis: an Exokernel

21. Processor Time Slices ◦ Represents the CPU as a linear vector. ◦ Scheduling is done “round robin”. ◦ Fairness: excess time counter.

22. Aegis: an Exokernel Processor Environment ◦ Exception context  program counter for where to jump to.  pointer to physical memory for saving registers. ◦ Interrupt context  program counters  register-save region.  separate program counters for start-time-slice and end- time-slice. ◦ Protected Entry context  synchronous and asynchronous. ◦ Addressing context

23. Aegis: Base Costs

24. Aegis: Exceptions Dispatches all hardware exceptions to applications. Saves three scratch registers into an agreed- upon “save area.” It loads the exception program counter. It uses the cause of the exception to perform an indirect jump to an application- specified program counter value.

25. Aegis: Exceptions

26. Aegis: Address Translations On TLB miss ◦ Aegis checks which segment the virtual address resides in. ◦ The application looks up the virtual address in its page-table structure. ◦ Aegis checks that the given capability corresponds to the access rights requested by the application. ◦ Cleanup and resumes execution.

27. Aegis: Protected Control Transfers Syrrchronous ◦ donate the current time and all future instantiation. Asynchronous ◦ Donate only the remainder of the current time slice to the callee.

28. Aegis: Dynamic Packet Filter (DPF) Dynamic code generation approach. ◦ compiling packet filters to executable code ◦ optimize executable code.

29. ExOS: a Library Operating System IPC Abstractions ◦ pipe: measures the latency of sending a word- sized message. ◦ shm: measures the time for two processes to “ping-pong” using a shared counter. ◦ lrpc: this experiment measures the time to perform an LRPC into another address space, increment a counter and return its value.

30. ExOS: IPC Abstractions

31. ExOS: Application-level Virtual Memory

33. ExOS: Application-Specific Safe Handlers (ASH) Downloaded code Direct, dynamic message vectoring. Dynamic integrated layer processing (ILP). Message initiation. Control initiation.

34. Extensibility with ExOS Extensible RPC

35. Extensible Page-table Structures Applications with Dense address space can use linear page tables. Applications with sparse address space can use inverted ones.

36. Extensible Schedulers Stride scheduling: Deterministic proportional- share

37. Conclusion Simplicity and limited number of exokemel primitives Exokemel primitives are fast ◦ low-level secure multiplexing of hardware resources can be implemented efficiently. Traditional operating system abstractions can be implemented efficiently at application level. Applications can create special-purpose implementations of abstractions by merely modifying a library.

38. Thanks