EXTENSIBILITY, SAFETY AND PERFORMANCE IN THE SPIN OPERATING SYSTEM

1. EXTENSIBILITY, SAFETY AND PERFORMANCE IN THE SPIN OPERATING SYSTEM B. Bershad , S. Savage, P. Pardyak , E. G. Sirer, D. Becker, M. Fiuczynski, C. Chambers, S. Eggers U. of Washington

2. Goals • To provide kernel extensibility • Without compromising kernel safety • Unlike Windows • Without compromising kernel performance • Unlike micro-kernel based systems Extensibility means here adding new features to the kernel , not just installing device drivers

3. Four basic techniques • Co-location of extensions in kernel address space • Enforced modularity through use of Modula-3, which enforces interface boundaries between modules • Logical protection domains: kernel namespaces that contain code and exported interfaces • Dynamic binding

4. System overview • Set of extension services and a core system • Primarily written in Modula-3 • Does not require applications to be written in any specific language • Used SPIN to implement a UNIX OS server • Bulk of server is written in C and runs within its own address space

5. Extensions • Can be loaded into the kernel at any time • Think of plug and play • Have used extensions to implement specialized versions of SPIN • Client/server video system

6. Client/server video system • Built SPIN extensions for a video service • Server extension provides direct in kernel path from disk to network • Client extension decompresses incoming video packets and sends them to the video frame buffer

7. Motivation • Most OS balance generality and specialization • Can tailor OS for specific applications • Not without degrading performance of other applications • Both Windows and [old] MacOS allow application programmers to modify data structures and code • Makes system less stable and less secure

8. Current state of the art UNIX safe fast Mach Windows extensible

9. Previous Work • Hydra: • Allowed applications to manage resources through multi-level policies • Used a weighty capability-based protection mechanism

10. Previous Work (continued) • Microkernels: • Very extensible (in user space) • High communication overhead of cross-domain calls • Nearly 100 times cost of regular procedure call • Acceptable only for coarse-grained services

11. Previous Work (continued) • Write extensions in “little languages” • Allows extensions written in these languages to be added into the kernel • Extension code is interpreted by kernel at run time • Limited scope of language limits usefulness of approach

12. Previous Work (continued) • Use software-fault isolation techniques • Allows collocation of extensions in kernel address space • Extensions can be written in any language • Uses a binary tool that inserts explicit checks around memory references and branch instructions • Not yet proven

13. Previous Work (continued) • Aegis • Had an efficient trap redirection mechanism • Implemented OS services as libraries executing in an application address space • Pilot et al. • Relied on language features to provide protection inside a shared address space

14. SPIN Architecture • Provides a software infrastructure for safety • Protection model supports efficient fine-grained access control of resources • Extension model allows extensions to be defined at the granularity of a procedure call • Makes few demands on the hardware • Relies on language to enforce safety

15. Modula-3 • Supports interfaces • They declare visible parts of an implementation module: all other definitions are hidden • Restriction is enforced at compile-time • Is type-safe: • Restriction is enforced through type-specific pointers, checks on array indexes and automatic storage management

16. 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

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

18. Operations on domains (I) • Create: initializes a domain with the contnst of a safe object file • Resolve: resolves any unresolved symbols in a target domain against symbols exported from a source domain Target has A unresolved Source exports A

19. Operations on domains (II) • Combine: creates linkable namespaces that are the union of existing domains

20. The extension model • SPIN extension model • Provides a controlled communication facility between extensions and base system • Allows for a variety of communication styles • Extensions can passively monitor the system, offer hints or even entirely replace a system service

21. Performance • SPIN offers the option of protected in-kernel calls that are much cheaper than a system call • SPIN has lower virtual memory operation overhead than other OSes: • SPIN uses kernel extensions to define application-specific system calls

22. Conclusions • Can combine extensibility, safety and performance in a single system • Static type-checking mechanisms, implemented through the Modula-3 compiler, make this possible