EXTENSIBILITY SAFETY AND PERFORMANCE IN THE SPIN OPERATING

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

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

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

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

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

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

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

Current state of the art UNIX safe fast Mach extensibl e Window s

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

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

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

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

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

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

Modula-3 • Supports interfaces – They declare visible parts of an implementation module: all other definitions are hidden – Restriction is enforced at compiletime • Is type-safe: – Restriction is enforced through typespecific pointers, checks on array

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

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

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

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

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

Performance • SPIN offers the option of protected inkernel 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

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