Extensible Kernels

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 handlers P2 predicates P1 P3 event • Execution of handlers can be • Synchronous/ asynchronous • Bounded in time • Ordered/unordered

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