Sealing OS Processes to Improve Dependability and Safety Galen Hunt, Mark Aiken, Manuel Fähndrich, Chris Hawblitzel, Orion Hodson, James Larus, Steven Levi, Bjarne Steensgaard, David Tarditi, and Ted Wobber Microsoft Research One Microsoft Way Redmond, WA 98052 USA [email protected] ABSTRACT General Terms In most modern operating systems, a process is a Design, Reliability, Experimentation. hardware-protected abstraction for isolating code and data. This protection, however, is selective. Many common Keywords mechanisms—dynamic code loading, run-time code Open process architecture, sealed process architecture, sealed generation, shared memory, and intrusive system APIs— kernel, software isolated process (SIP). make the barrier between processes very permeable. This paper argues that this traditional open process architecture 1. INTRODUCTION exacerbates the dependability and security weaknesses of Processes debuted, circa 1965, as a recognized operating modern systems. system abstraction in Multics [48]. Multics pioneered As a remedy, this paper proposes a sealed process many attributes of modern processes: OS-supported architecture, which prohibits dynamic code loading, self- dynamic code loading, run-time code generation, cross- modifying code, shared memory, and limits the scope of process shared memory, and an intrusive kernel API that the process API. This paper describes the implementation permitted one process to modify directly the state of of the sealed process architecture in the Singularity another process. operating system, discusses its merits and drawbacks, and Today, this architecture—which we call the open process evaluates its effectiveness. Some benefits of this sealed architecture—is nearly universal. Although aspects of this process architecture are: improved program analysis by architecture, such as dynamic code loading and shared tools, stronger security and safety guarantees, elimination memory, were not in Multics’ immediate successors (early of redundant overlaps between the OS and language versions of UNIX [35] or early PC operating systems), runtimes, and improved software engineering. today’s systems, such as FreeBSD, Linux, Solaris, and Conventional wisdom says open processes are required for Windows, embrace all four attributes of the open process performance; our experience suggests otherwise. We architecture. present the first macrobenchmarks for a sealed-process The open process architecture is commonly used to extend operating system and applications. The benchmarks show an OS or application by dynamically loading new features that an experimental sealed-process system can achieve and functionality directly into a kernel or running process. performance competitive with highly-tuned, commercial, For example, Microsoft Windows supports over 100,000 open-process systems. third-party, in-kernel modules ranging in functionality Categories and Subject Descriptors from device drivers to anti-virus scanners. Dynamically D.2.3 [Software Engineering] Coding Tools and Techniques; loaded extensions are also widely used as web server D.2.4 [Software Engineering] Software/Program Verification; extensions (e.g., ISAPI extensions for Microsoft’s IIS or D.4.1 [Operating Systems]: Process Management; D.4.5 modules for Apache), stored procedures in databases, [Operating Systems]: Reliability; D.4.6 [Operating Systems]: email virus scanners, web browser plug-ins, application Organization and Design; D.4.7 [Operating Systems]: Security plug-ins, shell extensions, etc. While the role of open and Protection. processes in Windows is widely recognized, like any versatile technology they are widely use in other systems Permission to make digital or hard copies of part or all of this work for as well [10, 42]. personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy 1.1. Problems with Open Processes otherwise, to republish, to post on servers, or to redistribute to lists, Systems that support open processes almost always requires prior specific permission and/or a fee. EuroSys’07, March 21–23, 2007, Lisbon, Portugal. implement process isolation through hardware mechanisms Copyright 2007 ACM 978-1-59593-636-3/07/0003 such as memory management protection and differentiated user and kernel instructions [37]. These mechanisms are We can draw an instructive analogy between sealed not free, and their cost is a major motivation for open processes and sealed classes in object-oriented languages. processes. In Aiken et al. [2], we measured hardware Experience with programming languages has shown that isolation costs ranging from 2.5% (in a compute-bound class designers and implementers need mechanisms to task with no paging) to 33% (in an IPC-bound task). This limit class extension and to force extensions to use overhead arises from page table management and cache declared interfaces, in order to enforce a software and TLB misses. architecture and reduce implementation errors [7]. Similarly, sealed processes offer application developers Developers avoid the performance overhead of hardware explicit and enforceable interfaces for extensions. protection by using the open process architecture to closely couple software components. Software components Dynamic code loading also imposes less visible penalties located in a common process can communicate through on performance and correctness. A host program that can shared data structures and use simple mechanisms, such as load code is an open environment in which it is difficult to procedure calls, to transfer control. These mechanisms are make sound assumptions about states, invariants, or valid particularly attractive because programming languages transitions. Consider, for example, the Java Virtual provide far richer data and control structures within a Machine (JVM). An interrupt, exception, or thread switch process than between processes. can invoke code that loads a new file, overwrites class and method bodies, and modifies global state to change code Not surprisingly, the open process architecture has semantics [41]. This possibility either limits permissible drawbacks. In particular, eliminating the isolation between compiler optimizations or requires extensive run-time a host process and an extension is a major source of support to recompile affected code. software reliability, security, and compatibility problems. Although extensions are rarely trusted, verified, or fully In addition, static program analysis, which underlies both correct, they are routinely loaded directly into a host kernel compiler optimizations and static defect detection, is or process, with no hard interface or boundary between complicated by open processes. A code extension must be host and extension. The outcome is often unpleasant. For analyzed in the context of its host environment, which can example, Swift reports that faulty device drivers cause be complicated and expensive to specify and model [4]. 85% of diagnosed Windows system crashes [43]. The host itself cannot be fully or accurately analyzed Unpublished data from Microsoft Online Crash Analysis without complete specification of extensions’ behavior. To tools shows that in-process extensions are an important be practical, defect detection tools make assumptions source of failure in many software products, including about absent code that reduce the quality of their results. Windows, Word, Outlook, Exchange, and Internet Explorer. Results from a static analysis survey [9] suggest 1.2. Contributions that in-process and in-kernel extensions are a major source This paper defines a new sealed process architecture that of errors in open source code as well. addresses many shortcomings of the open process architecture. We describe the implementation and our early Open processes also weaken enforcement of security experience with a sealed process system. We present the policies. Few, if any, operating systems provide a strong first macrobenchmark results showing that a sealed- guarantee of application identity or include applications as process system can have performance competitive with principals in access control decisions. The complete code open-process systems even when the sealed-process running in an open process cannot be known a priori, so system is written in a safe language with garbage an access control decision based on the identity of the collection. We also present an analysis of the costs of program started in the process would be suspect. Instead, trade-offs of moving a major software component, the most systems control access to data based on the identity register allocator of a compiler, to a child process. of an authenticated user [51]. With the sealed process architecture, the OS ensures that In practice, the open process architecture also impairs code in a process cannot be altered once the process starts software engineering. An extension gains unrestrained executing. The system prohibits dynamic code loading, access to its host’s memory. Extensions can, and self-modifying code, cross-process sharing of memory, frequently do, reach inside their host’s implementation to and provides a process-limited kernel API. access private data structures or functions. These undocumented and unwanted dependencies constrain the Sealed processes offer many advantages. They increase the evolution of the host program and require software ability of program analysis tools to improve