Singularity Reviewed an Operating System Challenging Common Concepts

Transcription

1 an Operating System Challenging Common Concepts by Lothar Schäfer Overview Singularity is a research operating system at Microsoft Research. The project started in 2003 and is the largest cross discipline project at Microsoft Research. It combines research in the fields of operating systems, networking, programming languages, programming tools and compilers. It s not intended for the commercial market. It should rather be seen as a test bed for trying out new ideas in operating system design, operating system concepts, program verification, compiler techniques and more. About 12 researchers are working full time and ca. 40 more are involved in the project. The projects two lead researchers are James Larus, concerned with programming languages, programming tools and parallel computation and Galen Hunt concerned with operating systems. Singularity is now at version 2, the research has spread from Microsoft Research to about six universities which became access to the source code. The following description is - due to the unavailable source code - based on several publications, presentations and papers from members of the singularity research team, which can all be downloaded from Beside the publications the site also contains some additional features like video presentations of Singularity s design concepts and architecture or links to web pages of several team members. 1 Introduction Every operating system embodies a collection of design decisions - some explicit, some implicit. These decisions include the choice of implementation language, the program protection model, the security model, the system abstractions, and many others. Contemporary operating systems like Windows, Linux, Mac OS X, and BSD - share a large number of design decisions. This commonality is not entirely accidental, as these systems are all rooted in OS architectures and development tools of the late 1960 s and early 1970 s. Given the common operating environments, the same programming language, and similar user expectations, it is not surprising that designers of these systems made similar decisions. While some design decisions have withstood the test of time, others have aged less gracefully [1]. Since then, computer science has changed in many ways. The machines became fast, the memory became cheap and computers are ubiquitous. On the other hand, the computing environment became malicious due to worms, viruses, scams, attacks and other bad surprises waiting around the corner [2]. So the design decisions should not be the same any longer, they need a change. To solve this problem, singularity has - from the beginning - been driven by the following question: What would a software platform look like if it was designed from scratch with the primary goal of dependability and trustworthiness? [1] Software dependability should in this case be understood as an amalgam of reliability, availability, safety, and security [3]. 1 / 8

2 Figure 1: Time of Detection or Correction It s possible to develop the above question into an actual approach, which is shown in figure 1. It states: Try to move as many sources of unreliability and their mitigation as far to the left as possible on the time axis. For example, moving the detection and correction of incorrect DLL binding from load time and run time to install time would eliminate DLL Hell [4]. To reach this goal, the Singularity project started with the following firm architectural principles: If the software fails, the system should not fail. The system should be self describing. Verify as many system aspects as possible. Those principles itself lead to three design issues: Use safe programming languages everywhere: A safe programming language ensures type safety and memory safety, where type safety ensures that the only operations applied to a value are those defined for instances of its type. Memory safety ensures the validity of memory references by preventing null pointer references, references outside an array s bounds, or references to deallocated memory. These properties can be partially verified by a compiler, but in some circumstances require run-time tests. Java and C# are expressive, safe programming languages that can be compiled with a small performance penalty for safety [5]. Improve system resilience despite software errors: The resilience can be improved by providing failure boundaries between components that permit part of a system to fail without compromising the whole. Another way to improve the resilience is to improve the extension model, which prevents kernel corruption through incorrect or malicious operations and inconsistent data after extension failure. If a failure happens the error notification should be explicit and cleanly propagated. Enable modular verification: This can be approached, if the system is made self-describing, so pieces can be examined in isolation. A program s behaviour could then be specified and checked at many levels of abstraction, and the automated analysis would become easier [2]. Figure 2: Interacting Improvements Figure 2 shows, that it is not possible to change one of these issues without globally affecting the others. 2 / 8

3 All mentioned design issues brought together end up in a new design choice that combines three key ideas. 2 Key Ideas The excessive use of safe programming languages enables the first key idea - Software Isolated Processes. Software Isolated Processes allow programs to run in their own software protected environment. On the other hand inter process communication cannot be done via shared memory. Doing this would break down the concept of a closed object space. The second key idea brings the solution to this problem - Contract Based Channels. The communication between Software Isolated Processes is done via Contract Based Channels, which enables the verification and control of messages between processes. Verification allows a process to interact with a second process only within predefined safety boundaries. The third key idea deals with applications running under singularity. In Singularity, an application consists of a manifest and a collection of resources. The manifest describes the application in terms of its resources and their dependencies. Although many existing setup descriptions combine declarative and imperative aspects, Singularity manifests contain only declarative statements that describe the desired state of the application after installation or update [6]. 2.1 Software Isolated Processes Software isolated processes (SIPs) use - as the name already implies - software verification, rather than hardware protection, to isolate portions of a system. They rely on verifying code s safe behavior to prevent it from accessing another process s (or the kernel s) instructions or data. A verifiably safe program can only access data that it allocated or was passed, and it cannot construct or corrupt a memory reference. In Singularity, all untrusted code that runs in a SIP must be verifiably safe. The SIP may also contain trusted, unverified code that cannot be expressed in a safe language, for example, parts of the language runtime, a memory allocator, or an accessor for memory-mapped I/O. The correctness and safety of this type of code needs to be verified by other means. Figure 3: Software Isolated Process A SIP is a closed object space that resides on a collection of memory pages exclusively owned by a process. An object space is the complete collection of objects reachable by a program at a point in its execution. Singularity ensures that two processes objects spaces are always disjoint. Since the code in the processes is safe, the only way in which one process could obtain a reference to another process s object is to be passed it (see figure 3). Singularity prevents crossprocess references by not providing shared memory and by using the language type system to prevent a process from sending an object reference through the interprocess communication mechanism [5]. To enable concurrency, SIPs contain Lightweight threads. All threads are kernel threads that are visible to the kernel s scheduler, which coordinates blocking operations. Singularity uses linked stacks to reduce thread memory overhead. These stacks grow on demand by adding non- 3 / 8

4 contiguous segments of 4K or more. The standard Singularity scheduler is optimized for a large number of threads that communicate frequently. SIPs are sealed code spaces. As a sealed process, a SIP cannot dynamically load or generate code into itself. Sealed processes demand a common extension mechanism for both the OS and applications: extension code can only execute in a new process, distinct from its host s SIP. Sealed processes offer a number of advantages. They increase the ability of program analysis tools to detect defects statically. They enable stronger security mechanisms, such as identifying a process by its code content. Context switches between SIPs have very low overhead as TLBs and virtually addressed caches need not be flushed. On termination, a SIP s resources can be efficiently reclaimed and its memory pages recycled without involving garbage collection. The low cost makes it practical to use SIPs as a fine-grain isolation and extension mechanism to replace the conventional mechanisms of hardware protected processes and unprotected dynamic code loading [1]. 2.2 Contract Based Channels In Singularity, all interprocess communication occurs through message passing across channels, which allows two processes to exchange data through an area of memory called the exchange heap. Messages in this heap are structs, not objects (i.e., they do not contain methods) and cannot contain object references. Messages, however, can contain references to exchange heap data, so it is possible to send structured data between processes. However, an object reference cannot be embedded in a message or sent between processes. Moreover, the system maintains the invariant that there exists at most one pointer to an item in the exchange heap. When a process sends a message, it loses its reference to the message, which is transferred to the receiving process (analogous to sending a letter by postal mail). Therefore, processes cannot use this heap as shared memory and messages can be exchanged through pointer passing, not copying [5]. The other significant difference that comes with CBCs is: communication across a channel is described by a channel contract. Figure 4: Example of a Channel Contract 4 / 8

5 Channel contracts are central to Singularity s isolation architecture and are directly supported in Singularity s programming language Sing#. Figure 4 shows an example contract describing a simple interaction on a channel. A contract consists of message declarations and a set of named protocol states. Message declarations state the number and types of arguments for each message and an optional message direction. Each state specifies the possible message sequences leading to other states in the state machine. So beside handling the message passing, a contract describes a state machine. This automatically delivers another advantage. Channels enable efficient and above all analyzable communication between SIPs. When combined with support for linear types, Singularity allows zero-copy exchange of large amounts of data between SIPs access channels. In addition, the Sing# compiler can statically verify that send and receive operations on channels never are applied in the wrong protocol state. A separate contract verifier can read a program s byte code and statically verify which contracts are used within a program and that the code conforms to the state machine described in the contract s protocol [1]. 2.3 Manifest Based Programs The third foundational architecture feature common to Singularity systems is the Manifest-Based Program (MBP). A MBP is a program defined by a static manifest. No code is allowed to run on a Singularity system without a manifest. In fact, to start execution, a user invokes a manifest, not an executable file as in other systems. A manifest describes an MBP s code resources, its required system resources, its desired capabilities, and its dependencies on other programs. When an MBP is installed on a system, the manifest is used to identify and verify that the MBP s code meets all required safety properties, to ensure that all of the MBP s system dependencies can be met, and to prevent the installation of the MBP from interfering with the execution of any previously installed MBPs. Before execution, the manifest is used to discover the configuration parameters affecting the MBP and restrictions on those configuration parameters. When an MBP is invoked, the manifest guides the placement of code into a SIP for execution, the connection of channels between the new SIP and other SIPs, and the granting of access to system resources by the SIP. Figure 5: A Program Manifest 5 / 8

6 A manifest is more than just a description of a program or an inventory of a SIP s code content; it is a machine-checkable, declarative expression of the MBP s expected behavior. The primary purpose of the manifest is to allow static and dynamic verification of properties of the MBP. For example, the manifest of a device driver provides sufficient information to allow installtime verification that the driver will not access hardware used by a previously installed device driver [1]. To facilitate static verification of as many run-time properties as possible, code for Singularity MBPs is delivered to the system as compiled Microsoft Intermediate Language (MSIL) binaries. MSIL is the CPU-independent instruction set accepted by the Microsoft Common Language Runtime. Every component in Singularity is described by a manifest, including the kernel, device drivers, and user applications. This is especially helpful in creating self-describing device drivers with verifiable hardware access properties [1]. 3 Architecture Singularity is a microkernel architecture (which is not entirely true, because in version 2, it s possible to merge software isolation and hardware protection into a hybrid system) nearly entirely written in Sing#, which is an extension to the Spec# language developed in Microsoft Research. Spec# itself is an extension to Microsoft s C# language that provides constructs (preand post-conditions and object invariants) for specifying program behavior. Figure 6 depicts the architecture of the Singularity OS, which is built around three key abstractions: a kernel, softwareisolated processes, and channels. The kernel provides the core functionality of the system, including memory management, process creation and termination, channel operations, scheduling, and I/O. Like other microkernels, most of the system s functionality and extensibility exist in processes outside of the kernel. Figure 6: System Architecture A Singularity system lives in a single virtual address space. Virtual memory hardware is used to protect pages, for example by mapping out the first 16K of address space to trap null pointer references. Within a Singularity system, the address space is logically partitioned into: a kernel object space, an object space for each process, and the Exchange Heap for channel data (see Contract Based Channels). A pervasive design decision is the memory independence invariant: cross-object space pointers only point into the Exchange Heap. In particular, the kernel does not have pointers into a process s object space, nor does one process have a pointer to another process objects. This invariant ensures that each process can be garbage collected and terminated without the cooperation of other processes. Each process has its own runtime system, with its own memory layout, garbage collection algorithm, and libraries. Because of memory independence, a runtime can be tailored to meet the needs of a computation. Garbage collection is an essential component of most safe languages, as it prevents memory deallocation errors that 6 / 8

7 can subvert safety guarantees. In Singularity, the kernel and processes object spaces are garbage collected. The kernel and each SIP has its own collector that is solely responsible for collection of objects in the object space. From the garbage collector s perspective, when a thread of control enters or leaves an application (or the kernel) it is treated similarly to a call to or a call-back from native code in conventional garbage collected environments. Garbage collection for different object spaces can therefore be scheduled and run completely independently. Singularity processes communicate exclusively by sending messages over channels, which are a bidirectional, behaviorally typed connection between two processes. When data is sent over a channel, ownership passes from the sending process, which may not retain a reference to the message, to the receiving process. This ownership invariant is enforced by the language and run-time systems, and serves three purposes. In addition to the usual mechanism of message-passing channels, processes communicate with the kernel through a strongly versioned application binary interface (ABI) that invokes static methods in kernel code. The ABI ensures a minimal, secure, and isolated computation environment for each SIP. So this interface (with about 192 methods) also follows the design of the rest of the system and isolates the kernel and process object spaces. All parameters to this ABI are values, not pointers, so the kernel and process s garbage collectors need not coordinate. The ABI maintains the system-wide state isolation invariant: a process cannot alter the state of another process using the ABI (with only two exceptions) [6]. 4 Verification Since the integrity of the SIPs depends on language safety and on a system-wide invariant that a process does not hold a reference into another process s object space, it s obvious, that Singularity relies on verification. Verifying that code executed in Singularity is type safe and satisfies the memory independence invariants is a three-stage process, depicted in figure 7. The Sing# compiler checks type safety, ownership rules, and protocol conformance during compilation. The Singularity verifier checks these same properties on the generated MSIL code. Finally, the back-end compiler should - but does not as yet - produce a form of typed assembly language that enables these properties to be checked on compiled code yet again by the operating system. One could argue that only the final stage is strictly necessary for safety. This is of course literally true, but in practice, programmers benefit from finding mistakes as early as possible and from having the errors explained completely, at a high level [6]. Figure 7: Compilation Pipeline 7 / 8

8 Summary Singularity is a microkernel operating system that uses advances in programming languages and compilers to build lightweight, software isolated processes, which provide code with protection and failure isolation at lower overhead than conventional, hardware supported processes. Singularity provides an isolation boundary by running verifiably safe programs and by preventing object pointers from passing between processes object spaces. SIPs, in turn, enable a new solution to the problem of code extension in systems and applications. In Singularity s model, extensions are not loaded into their parent process, but instead run in their own process and communicate over strongly typed channels. This model fixes some of the major problems with extensions, since in Singularity, they cannot directly access their parents data or interfaces, and, if they fail, they can be easily terminated by killing their parents. Singularity is above all a laboratory for exploring interactions among system architecture, programming languages, compilers, specification, and verification. Advances in each of these areas enable and reinforce advances in the others domains, which limits the benefit and impact of studying an area in isolation. Singularity is small and well structured, so it is possible to make changes that span the arbitrary boundaries between these domains. At the same time, it is large and realistic enough to demonstrate the practical advantages of new techniques [6]. Bibliography [1] Singularity: Rethinking the Software Stack, Galen C. Hunt, James R. Larus, Operating Systems Review, Vol. 41, Iss. 2, pp , April [2] Singularity: Rethinking the Software Stack, James R. Larus, Distinguished Lecture, University of Pennsylvania, November [3] {End Bracket} Singularity, James R. Larus, Galen C. Hunt, and David Tarditi. MSDN Magazine, Vol. 21, No. 7, p. 172, Microsoft Corporation, Redmond, WA, June [4] Singularity Design Motivation (STR 1), Galen C. Hunt and James R. Larus, Microsoft Research Technical Report MSR-TR , Microsoft Corporation, Redmond, WA, December [5] Deconstructing Process Isolation, Mark Aiken, Manuel Fähndrich, Chris Hawblitzel Galen C. Hunt, and James R. Larus. ACM SIGPLAN Workshop on Memory Systems Correctness and Performance (MSPC 2006) at ASPLOS 2006, San Jose, CA, October [6] An Overview of the Singularity Project, Galen C. Hunt, James R. Larus a.o., Microsoft Research Technical Report MSR-TR , Microsoft Corporation, Redmond, WA, October [7] Singularity Overview, Galen C. Hunt and James R. Larus, Microsoft Research Faculty Summit, July Table of Figures Figure 1: Time of Detection or Correction Source: Singularity Design Motivation (STR 1), Galen C. Hunt and James R. Larus, Microsoft Research Technical Report MSR-TR , Microsoft Corporation, December 2004, p.3. Figure 2: Interacting Improvements Pennsylvania, November 2006, p.6. Figure 3: Software Isolated Process Pennsylvania, November 2006, p.10. Figure 4: Example of a Channel Contract Pennsylvania, November 2006, p.31. Figure 5: A Program Manifest Pennsylvania, November 2006, p.31. Figure 6: System Architecture Pennsylvania, November 2006, p.30. Figure 7: Compilation Pipeline Singularity Overview, Galen C. Hunt and James R. Larus, Microsoft Research Faculty Summit, July 2006, p.28 8 / 8