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, RW) @ bind time Check capability @ access time Capability passing to share resources

Multiplexing the Network Application-specific Safe Handler (ASH) Download code into kernel (compiled to m/c

code @ 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)

Types1. Asynchronous

(donate only current time slice to callee)

2. Synchronous

L3Entering kernel – 71 cyclesExiting 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

36From 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 CallSockets, 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