单片内核对于计算机来讲还不够好,因此对于此本章节就对此做出了补充,可扩展的内核以及容器,本章节就计算机内核以及计算机外核做了具体的介绍,以及他们的对比,对于内核以及外核目前还有什么样的不足和需要补充的。

注脚

展开查看详情

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