可拓展操作系统：自旋，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