1. Extensible Kernels Mingsheng Hong

2. OS Kernel Types Monolithic Kernels Microkernels – Flexible (?) – Module Design – Reliable – Secure Extensible Kernels – Can be customized (extended, specialized, replaced) More functionality Better performance

3. Motivations Problems in traditional OS kernels – Implementation cannot be modified LRU as general page replacement strategy – Hide information of machine resources Not always appropriate in achieving high performance – database on top of file system – Provide a unified interface (overly general) Trade-offs for different applications – page table structure

4. Approaches Exokernel: safely expose machine resources – Higher-level abstractions are implemented in applications – The concept of Library OS – Safety ensured by secure bindings SPIN: use kernel extensions to safely extend/change OS services/implementations – Event-driven model to customize services – Efficiency preserved – Safety ensured by PL facilities

5. Exokernel: Overview An extension of RISC philosophy Kernel provides minimum services – Hardware resource protection Allocation Revocation Sharing Tracking of ownership – Resource usage arbitration Including an abort protocol LibOS as powerful as traditional OS

6. Exokernel: OS Component Layout Exokernel

7. A Motivating Example *This example is borrowed from MIT website

8. The Reality …

9. If Exokernel is Used…

10. Exokernel: Design Principle To separate protection from management – Can protect resources without understanding them When knowledge of resource is required – Can leave decisions to applications by downloading code – Another level of indirection without sacrificing performance

11. Exokernel: Secure Bindings Why? – Library OSes are untrusted How? – Hardware mechanism TLB entry – Software caching STLB – Downloading application code

12. Secure Bindings Multiplexing physical memory – Records capabilities: ownership, R/W permissions (authorization at bind time) – Checks capabilities(authentication at access time) – Enables resource sharing (How?)

13. Secure Bindings via Downloading Code Multiplexing the network – Uses Application-specific Safe Handlers (ASHs) – Performance Eliminate kernel crossings Decouple latency-critical operations from process scheduling – Safety Can be verified and trusted

14. More on ASHs An ASH can serve as a – Packet filter – Computation unit checksumming – Message initiator – Control initiator

15. Issues in Resource Revocation Visible deallocation of resource – So that library OS has a chance to react e.g. when physical page “5” is deallocated – But could be less efficient Can combine invisible revocation Library OS can be prepared for such occasions But when application does not cooperate… – Abort Protocol – imperative revocation e.g. cpu time slice Need to leave some resource for each libOS – Guaranteed mapping

16. Experiment: Aegis & ExOS Aegis: an exokernel on MIPS-based DECstation – Xok: another exokernel for Intel x86 computers ExOS: the corresponding library OS – Virtual memory, IPC are managed at application level – Can be extended Performance compared with: Ultrix

17. Procedure and System Calls

18. Protected Control Transfers Suggested reasons (?) – Kernal crossing – TLB flush

19. ExOS: IPC, VM

20. ASH: Scalability

21. Conclusion Securely multiplexes hardware resources, to achieve more flexibility & efficiency – OS primitives – High level abstractions: VM, IPC – Implementation can be customized (libOS)

22. Some Issues Exokernel – Portability Library OS – Too much code in user space? – Not easy to customize? OSKit, SPIN – Should provide a standard interface? – Security

23. SPIN: an Extensible OS Uses language features to make a system – Extensible Dynamic linking & later binding – Safe Type safe language – Efficient In kernel space Modula-3 features: memory safe; interfaces

24. Traditional OSes *This picture is borrowed from Univ. of Washington website

25. SPIN Structure *This picture is borrowed from Univ. of Washington website

26. The Protection Model Pointers as capabilities – Types not forgeable – Determined at compile-time => efficient – Externalized when passed across domains An object is safe if – Verified by the compiler – Or asserted so by the kernel (objected implemented in other languages)

27. The Extension Model Events and handlers event handlers P1 P2 P3 Execution of handlers can be Synchronous/ asynchronous Bounded in time Ordered/unordered predicates

28. Core Services Services that cannot be safely implemented by extensions Simple functionality Fine grained control

29. Core Services: Memory Management Manage memory and processor resources – MM interfaces Storage: allocate, deallocate, reclaim Naming : allocate, deallocate Translation: add/remove/examine mapping – Exceptions PageNotPresent BadAddress ProtectionFault – Address space model can be defined on top of the primitives

30. Core Services: Thread Management Thread Management – Strand interface block/unblock checkpoint/resume – Global and application-specific schedulers – Thread model can be defined on top of the primitives Core services are trusted – Extensions should be fault-isolated

31. Performance I: Competitors DEC OSF/1: monolithic kernel Mach 3.0: microkernel SPIN: extensible kernel

32. Performance II: Microbenchmarks IPC Thread management

33. VM primitives Kernel crossings Overhead in demultiplexing exception (?)

34. Performance III: Networking Latency and bandwidth Packet forwarding

35. End-to-End Performance Networked Video System A dilemma in web server buffer management -- hybrid cache policy

36. Issues in SPIN Scalability of the event/handler model How to prioritize handlers? – Throughput vs. fairness Extensibility limited by interfaces

37. Conclusion Two methods to make OS more flexible & efficient Both reduce kernel crossings – Exokernel: libOS – SPIN: link extension code to kernel space