展开查看详情
1 .Modern systems: Extensible Kernels and Containers Hakim Weatherspoon CS6410 1
2 .Modern systems: Extensible Kernels and Containers Hakim Weatherspoon CS6410 1
3 .Motivation 3 Lots of problems…
4 .Motivation 4 Lots of problems…Lots of design opportunities!
5 .5 Motivation Extensibility Security Performance From Stefan Savage’s SOSP 95 presentation Can we have all 3 in a single OS?
6 .Context for these papers 1990’s Researchers (mostly) were doing special purpose OS hacks Commercial market complaining that OS imposed big overheads on them OS research community began to ask what the best way to facilitate customization might be. In the spirit of the Flux OS toolkit … 2010’s containers: single-purpose appliances Unikernels : (“sealable”) single-address space Compile time specialized
7 .Motivation 7 1988-1995: lots of innovation in OS development Mach 3, the first “true” microkernel SPIN , Exokernel , Nemesis, Scout , SPACE, Chorus, Vino, Amoeba, etc... And even more design papers
8 .Motivation 8 Exploring new spaces Distributed computing Secure computing Extensible kernels ( exokernel , unikernel ) Virtual machines ( exokernel ) New languages (spin) New memory management ( exokernel , unikernel )
9 .9 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
10 .Exokernel Dawson R. Engler , M. Frans Kaashoek and James O’Toole Jr. Engler’s Master’s Thesis. Follow-up publications on 1997 and 2002. Kaashoek later worked on Corey.
11 .11 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)
12 .12 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 .13 Exokernel Kernel only multiplexes hardware resources (Aegis) Higher-level abstractions in Library OS ( ExOS ) Secure binding, Visible resource revocation, Abort Apps link with the LibOS of their choice
14 .14 OS Component Layout Exokernel
15 .Exokernel main ideas Kernel Resource sharing, not policies Library Operating System Responsible for the abstractions IPC VM Scheduling Networking
16 .16 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
17 .Exokernel Architecture Exokernels . MIT CSAIL, 1998
18 .Exokernel vs Microkenels vs VM Exokernel defines only a low-level interface. A microkernel also runs almost everything on user-level, but has fixed abstractions. A VM emulates the whole machine, doesn’t provide direct access.
19 .Design 19 Application-level resource management Exports hardware resources Multiplexes access between processes Separates policy from management avoid resource management!
20 .What problems do we solve? 20 High-level abstractions hurt application performance Hide information Limit functionality Existing monolithic kernels Encourage stable (archaic) interfaces Difficult to extend with modern techniques
21 .How do we solve them: Design 21 Secure bindings Downloading code Visible resource revocation The abort protocol
22 .How do we solve them: Design 22 Secure bindings Downloading code Visible resource revocation The abort protocol
23 .Secure bindings 23 Decouples authorization from use Authorize once, at “bind time” Use transferable “capabilities” to check access Cache bindings in-kernel to decrease binding frequency Example : huge software-based TLB
24 .How do we solve them: Design 24 Secure bindings Downloading code Visible resource revocation The abort protocol
25 .Downloading code 25 Userspace application produces kernel space code Access checks at download time Code is verified before being run, with JIT for speed
26 .How do we solve them: Design 26 Secure bindings Downloading code Visible resource revocation The abort protocol
27 .Visible resource revocation 27 Revocation traditionally invisible (or transparent) Expensive : have to save entire state Try visible instead! Save only the state you need Kernel gives you a few microseconds to do it
28 .How do we solve them: Design 28 Secure bindings Downloading code Visible resource revocation The abort protocol
29 .29 Revocation: kernel asks process for resource “ relinquish page 5 please” Process tracks state and returns resource Abort : kernel demands resource “ page 5 in 50 microseconds” Takes resource “by force” Invalidates credentials and bindings . Notifies library operating system
热门城市
