1 Extensible Kernels Amar Phanishayee

2 Traditional OS services – Management and Protection Provides a set of abstractions Processes, Threads, Virtual Memory, Files, IPC Sys calls and APIs (eg: Win32, POSIX) Resource Allocation and Management Accounting Protection and Security Concurrent execution

3 Problems (examples coming-up) Extensibility Abstractions overly general Apps cannot dictate management Implementations are fixed Performance Crossing over into the kernel is expensive Generalizations and hiding information affect performance Protection and Management offered with loss in Extensibility and Performance

4 Need for Application controlled management (examples) Buffer Pool Management In DBs (*) LRU, prefetch (locality Vs suggestion), flush (commit) Shared Virtual Memory (+) use a page fault to retrieve page from disk / another processor

5 Examples (cont.) Concurrent Checkpointing (+) Overlap checkpointing and program being checkpointed Change rights to R-only on dirty pages Copy each page and reset rights Allow reads; Use write faults to {copy, reset rights, restart} * OS Support for Database Management (Stonebraker) + Virtual Memory Primitives for User Programs (Andrew W. Appel and Kai Li)

6 Examples (cont.) [Implementation and Performance of Application-Controlled File Caching - Pei Cao, et al.] Feedback for file cache block replacement

7 Down with monarchy! French Revolution - Execution of Louis XVI

8 Challenges Extensibility Security Performance

9 Extensible Kernels Exokernel (SOSP 1995): safely exports machine resources Higher-level abstractions in Library OS Secure binding, Visible resource revocation, Abort Apps link with the LibOS of their choice SPIN (SOSP 1995): kernel extensions (imported) safely specialize OS services Extensions dynamically linked into OS kernel Safety ensured by Programming Language facilities

10 Exokernels - Motivation Existing Systems offer fixed high-level abstractions which is bad Hurt app performance (generalization – eg: LRU) Hide information (eg: page fault) Limit functionality (infrequent changes – cool ideas don’t make it through)

11 Motivation (cont.) Separate protection from management, mgmt in user space Apps should use domain specific knowledge to influence OS services Small and simple kernel – adaptable and maintainable

12 OS Component Layout Exokernel

13 Lib OS and the Exokernel Lib OS (untrusted) can implement traditional OS abstractions (compatibility) Efficient (Lib OS in user space) Apps link with Lib OS of their choice Kernel allows LibOS to manage resources, protects LibOss

14 Exokernel : Design Principles Securely expose hardware Min resource management as required by protection (allocation, revocation) Expose allocation No implicit allocation Expose Names Expose Revocation Eg: two-level replacement

15 Exokernel : Secure Bindings Lib OSs are untrusted Authorization at bind time Authentication at access time (no need to understand semantics – eg: FS permissions, groups) Techniques Hardware (TLB) Software (STLB – Kavita) download code (direct procedure call, sandboxing, type-safe language)

16 Secure Bindings Multiplexing Memory Record capabilities (ownership, bind time Check access time Capability passing to share resources Multiplexing the Network Application-specific Safe Handler (ASH) Download code into kernel (compiled to m/c runtime) No kernel crossing; Procedure call instead of scheduling (low RTT)

17 Resource Revocation Visible Revocation “please return a memory page” “return a page within 50 microseconds” CPU revocation at the end of time-slice Invisible better when revocations are frequent (due to f/b) Abort To revoke resources “by force” from misbehaving processes repossession vector, repossession exception Worst case repossession (guarantee)

18 ExOS + Aegis Platform – MIPS-based DECstation Aegis – exokernel ExOS – library OS Processes, Virtual Mem, IPC, Network Protocols (ARP/RARP, IP, UDP) Comparison with Ultrix (tuned monolithic kernel)

19 Base Cost in microSec 12.5 MHz ~11MIPS 16.6 MHz ~15MIPS 25 MHz ~25MIPS Demultiplexing SysCalls expensive in Ultrix. May have TLB miss in Sys call!

20 “barebone” unidirectional Protected Control Transfer (microSec) Types 1.Asynchronous (donate only current time slice to callee) 2.Synchronous L3 Entering kernel – 71 cycles Exiting Kernel – 36 cycles TLB flush on context switch

21 Key to Aegis’ Performance Easy keeping track of ownership Provides very little apart from low level multiplexing Caching secure bindings (STLB) Dynamic code generation

22 ExOS IPC Pipe – shared mem; yield Pipe’ has code inlining Shm – Yield to switch (ExOS), Signals (Ultrix) RPC – single function, no look-up. Cost of emulation in Ultrix using pipes or signals is high

23 ExOS Virtual Memory + Fast Sys call. - Half the time in look-up (vector). Repeated access to Aegis STLB and ExOS PageTable

24 ASH and scalability Ping-pong of counter in a 60-byte UDP packet 4096 times between 2 processes in user space on DECStation5000/125 Without ASH - response on being scheduled. Round Robin scheduling -> linear increase in RTT.

25 Exokernel: Summary Minimal Kernel Secure multiplexing of resources Bind time Authorization Portability OS Abstractions in user space (Lib OS) VM, IPC Apps link with OS of their choice

26 SPIN Use of language features for Extensions Extensibility Dynamic linking and binding of extensions Safety Interfaces. Type safety. Extensions verified by compiler Performance Extensions not interpreted; Run in kernel space

27 Language: Modula 3 Interfaces Type safety Array bounds checking Storage Management Threads Exceptions

28 Motivation From Stefan Savage’s SOSP 95 presentation Can we have all 3 in a single OS?

29 SPIN structure From Stefan Savage’s SOSP 95 presentation

30 Protection model Capabilities Pointer as capability Type safe (compile time check) Externalized reference

31 Protection model (cont.) Protection “domain” exported interfaces of safe object files Safe object file = verified by compiler or asserted by the kernel In-kernel name server Optional authorization for importing i/f

32 Events and Handlers Events message announcing Change in state Request for service Procedure exported from an interface Handlers register for events Multiple handlers

33 Dispatcher Central dispatcher – event router Primary handler Handler invocation Synchronous/Asynchronous Bounded time Ordered/Unordered

34 Handler Installation From Brian Bershad’s OSDI 96 presentation

35 Handler Installation (cont.) From Brian Bershad’s OSDI 96 presentation

36 From Stefan Savage’s SOSP 95 presentation Event Handling

37 Core Services: Memory Management Services Physical storage : allocate, deallocate, “reclaim” (returns capability) Naming (virtual) : allocate, deallocate Translation (mapping) : add/remove/check mapping Exceptions BadAddress PageNotPresent Extensions use these primitives to define an address space model

38 Core Services: Thread Management Strand interface block/unblock checkpoint/resume Global and application-specific schedulers fault-isolation Thread model can be defined using these primitives

39 Microbenchmarks IPC In-kernel Call Sockets, SUN RPC Mesgs. Thread Mgmt All numbers are in microseconds

40 Performance: Virtual Memory In-Kernel calls are more efficient than traps or messages All numbers are in microseconds

41 Performance: Networking Lower RTT because of in-kernel extension time in microseconds, Bandwidth in Mbps

42 End-to-End Performance Networked Video Server CPU utilization (network interface supports DMA)

43 Issues Dispatcher scalability Handler scheduling Garbage collection

44 Conclusion Extensibility without loss of security or performance Exokernels Safely export machine resources Decouple protection from management SPIN kernel extensions (imported) safely specialize OS services Safety ensured by Programming Language facilities