Ted Pham 15-712 Software Systems March 9, 1999 Summary Extensibility, Safety and Performance in the SPIN Operating System SPIN is an operating system that aims to allow extensions and customizations to the kernel without sacrificing performance or system integrity. SPIN recognizes that the default policies built into the core kernel can be designed to work reasonably well for most applications. Yet there will always be cases where the default policies seriously hinder application performance. For instance, in client-server video systems, the default policies require the server to copy, once for each client, the same buffer from the disk into kernel space then into its user space then into kernel space again and finally out onto the network interface card. Likewise, each client must perform the same copying operations in reverse with the data ultimately destined for the video card's frame buffer. Using an extension that allows data to be directly copied from the disk to the network card and from the network card directly to the video card greatly increases the performance of this application. For these cases, SPIN wishes to allow customization without jeopardizing system integrity. Whereas other operating systems approach this problem by pushing kernel decision making out of the kernel and into user-land, SPIN allows these extensions to be dynamically linked directly into the kernel's address space. The SPIN creators would argue that pushing kernel decision making out into user-land leads to very coarse-grained interfaces. These coarse-grained interfaces result from amortizing the cost of expensive protection boundary switches. Thus SPIN's in kernel extensions allow quick access to the underlying core system services and other kernel extensions. This encourages fine-grained interfaces and more cooperation between extensions. On the other hand, allowing third parties to introduce code into the kernel usually leads to integrity problems. Since all the code is running in one address space, there is always the concern that one malfunctioning or malicious extension could damage or hinder other pieces of the kernel. SPIN's solution to this problem mandates that all kernel and extension code is written the type safe language Modula-3. SPIN's definition of protection is that an extension should not hinder nor damage the core kernel or other extensions. However, this does not guarantee that an extension does exactly what its programmer(s) intended. If an extension behaves incorrectly, only applications that depend on that extension should suffer. The SPIN paper identifies four concepts that allow SPIN to provide this protection yet maintain performance. They are: Co-location - Extensions dynamically linked into kernel virtual address space. Enforced modularity - Compiler enforces modular boundaries. Only access memory through explicit interfaces. Logical protection domains - Kernel namespaces that contain code and exported interfaces for each extension. Dynamic call binding: Extensions execute in response to events and can be dispatched via cheap procedure call. SPIN depends on the Modula-3 compiler to guarantee that an extension module only accesses other modules through defined interfaces. A Modula-3 interface declares the visible parts of an implementation module defining that interface. These interfaces provide fine grained protection boundaries. Also, since Modula-3 is a type safe language, code can never access memory arbitrarily. Compile time and link time checking prevent arbitrary pointer casting and bounds check array references. Though the SPIN kernel and extensions are written in Modula-3, applications can be written in any language. All resources in SPIN are accessed through capabilities. A capability is an unforgeable reference to a resource. This resource can be a system object, an interface, or a collection of interfaces. In the SPIN kernel, these capabilities are just pointer references which the compiler and linker check for type safety. Since application programs are not necessarily written in Modula-3, SPIN grants user applications access to these capabilities through external references. An external reference is an index into a per application table of type safe references and is similar to the concept of file descriptor tables. To simulate separate address space like protection between in kernel modules, SPIN uses protection domains. A protection domain is the set of names available to an execution context. They are implemented through Modula-3 namespaces. SPIN provides facilities for capability controlled cross-domain dynamic linking. Interfaces may be imported and exported across protection domains. The exporting module may also register an authorization procedure to identify those modules that import the interface. SPIN's extension model consists of event generation and handling mechanisms. An event is a message that announces a change in the state of the system or a request for service. A handler is a procedure that receives an event message. Extensions register handlers with a central dispatcher for specific events. The kernel can preempt handlers to ensure that no handler can maliciously or accidentally prevent other execution from continuing. If there is only one handler for an event, direct procedure calls are used. The primary right to handle an event belongs to the default implementation module for the event. The dispatcher contacts the default implementation when an extension tries to install a handler. The default implementation may deny or allow the handler's installation. This mechanism is used to indicate varying levels of trust in extension code and to prevent extension of some key kernel components. For instance, the module that controls kernel threading and synchronization can never be extended. The third element of SPIN's extension model is the guard. A guard is a predicate, expressed as a procedure, which the dispatcher evaluates prior to handler invocation. If the predicate evaluates to false, the handler is ignored. This allows handlers to be invoked on a per-instance basis. Any number of handlers can be installed for a given event. The default implementation module can force a handler to execute synchronously, asynchronously, in bounded time or in some arbitrary order with respect to other handlers for the same event. This further reflects the degree of trust that the default implementation has for an extension. The SPIN paper then goes on to discuss the design of the virtual memory system and thread management system in terms of events. This is followed by a number of benchmarks which show SPIN matching or bettering Mach and DEC-OSF1. This emphasizes that direct procedure calls used as protection boundaries are far faster then cross address space calls and copying. Thus SPIN's main contribution is that single address space computing with enforced protection boundaries is possible through the use of type safe languages and trusted type safe compiler and linking tools.