可拓展操作系统:自旋,Exo-kernel和L4

本章讲述了操作系统可扩展性:Spin,Exo-kernel和L4的主要内容。讨论了该系统所具有的点:操作更加简单和具有可拓展性。介绍了可扩展性的自旋方法,包含了自旋机制/工具箱、逻辑保护域等内容。
展开查看详情

1.OS Extensibility: Spin, Exo- kernel and L4 Jan 20, 2017 1

2. More simply Monolithic safe fast micro kernel DOS extensible 2

3. Extensibility •  Problem: How? •  Add code to OS –  how to preserve isolation? –  … without killing performance? •  What abstractions? –  General principle: mechanisms in OS, policies through the extensions –  What mechanisms to expose? 3

4.Spin Approach to extensibility •  Co-location of kernel and extension –  Avoid border crossings –  But what about protection? •  Language/compiler forced protection –  Strongly typed language •  Protection by compiler and run-time •  Cannot cheat using pointers –  Logical protection domains •  No longer rely on hardware address spaces to enforce protection – no boarder crossings •  Dynamic call binding for extensibility 4

5.SPIN MECHANISMS/TOOLBOX 5

6. Logical protection domains •  Modula-3 safety and encapsulation mechanisms –  Type safety, automatic storage management –  Objects, threads, exceptions and generic interfaces •  Fine-grained protection of objects using capabilities. An object can be: –  Hardware resources (e.g., page frames) –  Interfaces (e.g., page allocation module) –  Collection of interfaces (e.g., full VM) •  Capabilities are language supported pointers 6

7. Logical protection domains -- mechanisms •  Create: –  Initialize with object file contents and export names •  Resolve: –  Names are resolved between a source and a target domain •  Once resolved, access is at memory speeds •  Combine –  To create an aggregate domain •  This is the key to spin – protection, extensibility and performance 7

8. Protection Model (I) •  All kernel resources are referenced by capabilities [tickets] •  SPIN implements capabilities directly through the use of pointers •  Compiler prevents pointers to be forged or dereferenced in a way inconsistent with its type at compile time: –  No run time overhead for using a pointer

9. Protection Model (II) •  A pointer can be passed to a user- level application through an externalized reference: –  Indexinto a per-application table of safe references to kernel data structures •  Protection domains define the set of names accessible to a given execution context

10. Spin File CPU scheduler System File Memory System manager Network Memory CPU manager scheduler spin IPC, Address Spaces, … Hardware, managed by OS 10

11. Spin Mechanisms for Events •  Spin extension model is based on events and handlers –  Which provide for communication between the base and the extensions •  Events are routed by the Spin Dispatcher to handlers –  Handlers are typically extension code called as a procedure by the dispatcher –  One-to-one, one-to-many or many-to-one •  All handlers registered to an event are invoked –  Guards may be used to control which handler is used 11

12.Event example 12

13.PUTTING IT ALL TOGETHER 13

14.Default Core services in SPIN •  Memory management (of memory allocated to the extension) –  Physical address •  Allocate, deallocate, reclaim –  Virtual address •  Allocate, deallocate –  Translation •  Create/destory AS, add/remove mapping –  Event handlers •  Page fault, access fault, bad address 14

15. CPU Scheduling •  Spin abstraction: strand –  Semantics defined by extension •  Event handlers –  Block, unblock, checkpoint, resume •  Spin global scheduler –  Interacts with extension threads package 15

16. Experiments •  Don’t worry, I wont go through them •  In the OS community, you have to demonstrate what you are proposing –  They built SPIN, extensions and applications that use them –  Focus on performance and size •  Reasonable size, and substantial performance advantages even relative to a mature monolithic kernel 16

17. Conclusions •  Extensibility, protection and performance –  compiler features and run-time checks –  Instead of hardware address spaces –  …which gives us performance—no border crossing •  Who are we trusting? Consider application and Spin –  How does this compare to Exo-kernel? •  Concern about resource partitioning? –  Each extension must be given its resources –  No longer dynamically shared (easily) –  Parallels to Virtualization? 17

18.EXOKERNEL 18

19. Motivation for Exokernels •  Traditional centralized resource management cannot be specialized, extended or replaced •  Privileged software must be used by all applications •  Fixed high level abstractions too costly for good efficiency •  Exo-kernel as an end-to-end argument

20. Exokernel Philosophy •  Expose hardware to libraryOS –  Noteven mechanisms are implemented by exo-kernel •  They argue that mechanism is policy •  Exo-kernel worried only about protection not resource management

21. Design Principles •  Track resource ownership •  Ensure protection by guarding resource usage •  Revoke access to resources •  Expose hardware, allocation, names and revocation •  Basically validate binding, then let library manage the resource

22.Exokernel Architecture

23. Separating Security from Management •  Secure bindings – securely bind machine resources •  Visible revocation – allow libOSes to participate in resource revocation •  Abort protocol – break bindings of uncooperative libOSes

24. Secure Bindings •  Decouple authorization from use •  Authorization performed at bind time •  Protection checks are simple operations performed by the kernel •  Allows protection without understanding •  Operationally – set of primitives needed for applications to express protection checks

25. Example resource •  TLB Entry –  Virtual to physical mapping done by library –  Binding presented to exo-kernel –  Exokernel puts it in hardware TLB –  Process in library OS then uses it without exo-kernel intervention 25

26.Implementing Secure Bindings •  Hardware mechanisms: TLB entry, Packet Filters •  Software caching: Software TLB stores •  Downloaded Code: invoked on every resource access or event to determine ownership and kernel actions

27. Downloaded Code Example: (DPF) Downloaded Packet Filter •  Eliminates kernel crossings •  Can execute when application is not scheduled •  Written in a type safe language and compiled at runtime for security •  Uses Application-specific Safe Handlers which can initiate a message to reduce round trip latency

28. Visible Resource Revocation •  Traditionally resources revoked invisibly •  Allows libOSes to guide de-allocation and have knowledge of available resources – ie: can choose own ‘victim page’ •  Places workload on the libOS to organize resource lists

29. Abort Protocol •  Forced resource revocation •  Uses ‘repossession vector’ •  Raises a repossession exception •  Possible relocation depending on state of resource