Technical Report - Microsoft Research

• SIPs are created and terminated by the operating system, so that on termination, a SIP’sresources can be efficiently reclaimed.• SIPs executed independently, even to the extent of having different data layouts, run-timesystems, and garbage collectors.SIPs are not just used to encapsulate application extensions. Singularity uses a singlemechanism for both protection and extensibility, instead of the conventional dual mechanisms ofprocesses and dynamic code loading. As a consequence, Singularity needs only one errorrecovery model, one communication mechanism, one security policy, and one programmingmodel, rather than the layers of partially redundant mechanisms and policies in current systems.A key experiment in Singularity is to construct an entire operating system using SIPs anddemonstrate that the resulting system is more dependable than a conventional system.The Singularity kernel consists almost entirely of safe code and the rest of the system, whichexecutes in SIPs, consists of only verifiably safe code, including all device drivers, systemprocesses, and applications. While all untrusted code must be verifiably safe, parts of theSingularity kernel and run-time system, called the trusted base, are not verifiably safe. Languagesafety protects this trusted base from untrusted code.The integrity of the SIPs depends on language safety and on a system-wide invariant that aprocess does not hold a reference into another process’s object space.Ensuring code safety is obviously essential. In the short term, Singularity relies on compilerverification of source and intermediate code. In the future, typed assembly language (TAL) willallow Singularity to verify the safety of compiled code [36, 38]. TAL requires that a programexecutable supply a proof of its type safety (which can be produced automatically by a compilerfor a safe language). Verifying that a proof is correct and applicable to the instructions in anexecutable is a straightforward task for a simple verifier of a few thousand lines of code. Thisend-to-end verification strategy eliminates a compiler—a large, complex program—fromSingularity’s trusted base. The verifier must be carefully designed, implemented, and checked,but these tasks are feasible because of its size and simplicity.The memory independence invariant that prohibits cross-object space pointers serves severalpurposes. First, it enhances the data abstraction and failure isolation of a process by hidingimplementation details and preventing dangling pointers into terminated processes. Second, itrelaxes implementation constraints by allowing processes to have different run-time systems andtheir garbage collectors to run without coordination. Third, it clarifies resource accounting andreclamation by making unambiguous a process’s ownership of a particular piece of memory.Finally, it simplifies the kernel interface by eliminating the need to manipulate multiple types ofpointers and address spaces.A major objection to this architecture is the difficulty of communicating through messagepassing, as compared with the flexibility of directly sharing data. Singularity is addressing thisproblem through an efficient messaging system, programming language extensions that conciselyspecify communication over channels, and verification tools [19].2.1 ExtensibilitySoftware creators rarely anticipate the full functionality demanded by users of their systemor application. Rather than trying to satisfy everyone with a monolithic system, most non-trivialsoftware provides mechanisms to load additional code. For example, Microsoft Windowssupports over 100,000 third party device drivers, which enable it to control almost any hardwaredevice. Similarly, countless browser add-ons and extensions augment a browser’s interface andcomponents for web pages. Even open source projects—although theoretically modifiable—4