Extensible Kernels Mingsheng Hong

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

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

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

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

Exokernel: OS Component Layout Exokernel

A Motivating Example *This example is borrowed from MIT website

The Reality …

If Exokernel is Used…

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

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

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?)

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

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

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

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

Procedure and System Calls

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

ExOS: IPC, VM

ASH: Scalability

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

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

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

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

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

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)

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

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

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

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

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

Performance II: Microbenchmarks IPC Thread management

VM primitives Kernel crossings Overhead in demultiplexing exception (?)

Performance III: Networking Latency and bandwidth Packet forwarding

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

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

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