View
219
Download
0
Embed Size (px)
Citation preview
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
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
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
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
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