Singularity vs. the Hard Way Part 1 Jeff Chase Today • Singularity: abstractions User processes / • vs. the “Hard Way” (e.g., *i*x) VAS / segments – Processes vs. SIPs user – Protection: hard vs. soft – Kernel vs. microkernel kernel kernel – Extensibility: open vs. closed code+data • Questions – How is the kernel protected? – How does it control access to data? – How does it keep control? 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 Windows, embrace all four attributes of the open process ConventionalSealing OS Processes wisdom saysto Improve open processes Dependability are required and Safety, for EuroSys 2007 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 loaded extensions are also widely used as web server D.2.3 [Software Engineering] Coding Tools and Techniques; 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 Singularity OS Architecture channels • Safe micro-kernel content web TCP/IP network – 95% written in C# extension server stack driver • 17% of files contain unsafe C# • 5% of files contain x86 asm or C++ ext. server tcp driver – services and device drivers in processes class class class class library library library library • Software isolated processes (SIPs) processes – all user code is verifiably safe runtime runtime runtime runtime – some unsafe code in trusted runtime – processes and kernel sealed at start time kernel API • Communication via channels kernel kernel – channel behavior is specified and checked page mgr scheduler class – fast and efficient communication chan mgr library proc mgr • Working research prototype i/o mgr runtime – not Windows replacement HAL Singularity Processes and the kernel Programs Each process run as data data has a private independent virtual address processes. space and one or more threads. Protected ...and upcalls system calls, (e.g., signals) and faults, Protected OS Threads kernel enter the mediates kernel for access to OS shared services. resources. The kernel code and data are protected from untrusted processes. 310 Processes and the kernel • A (classical) OS lets us run programs as processes. A process is a running program instance (with a thread). – Program code runs with the CPU core in untrusted user mode. • Processes are protected/isolated. – Virtual address space is a “fenced pasture” – Sandbox: can’t get out. Lockbox: nobody else can get in. • The OS kernel controls everything. – Kernel code runs with the core in trusted kernel mode. 310 Threads I draw my threads like this. • A thread is a stream of control…. – Executes a sequence of instructions. – Thread identity is defined by CPU register context (PC, SP, …, page table base registers, …) – Generally: a thread’s context is its register values and referenced memory state (stacks, page tables). • Multiple threads can execute independently: – They can run in parallel on multiple cores... • physical concurrency – …or arbitrarily interleaved on some single core. • logical concurrency Some people draw threads as • A thread is also an OS abstraction to spawn and squiggly lines. manage a stream of control. 310 User/kernel user space Safe control transfer kernel code kernel space kernel data 310 Threads and the kernel process • Modern operating systems have multi- VAS threaded processes. data user mode • A program starts with one main thread, but user space once running it may create more threads. • Threads may enter the kernel (e.g., syscall). threads • (We assume that) threads are known to the OS kernel. trap – Kernel has syscalls to create threads (e.g., fault Linux clone). / resume • Implementations vary. – This model applies to Linux, MacOS-X, kernel mode Windows, Android, and pthreads or Java on kernel space those systems. 310 2.1 Software-Isolated Processes Like processes in many operating systems, a SIP is a holder of processing resources and provides the context for program execution. Execution of each user program occurs within the context of a SIP. Associated with a SIP is a set of memory pages containing code and data. A SIP contains one or more threads of execution. A SIP executes with a security identity and has associated OS security attributes. Finally, SIPs provide information hiding and failure isolation. Singularity: Rethinking the Software Stack 3.2. Software Isolated Processes A Singularity process is called a software isolated process (SIP): • A SIP consists of a set of memory pages, a set of threads, and a set of channel endpoints…. • A SIP starts with a single thread, enough memory to hold its code, an initial set of channel endpoints, and a small heap. • It obtains additional memory by calling the kernel’s page manager, which returns new, unshared pages. • These pages need not be adjacent to the SIP’s existing address space, since safe programming languages do not require contiguous address spaces. Sealing OS Processes to Improve Dependability and Safety Process Model • Process contains only safe code • No shared memory – communicates via messages • Messages flow over channels – well-defined & verified Software • Lightweight threads for concurrency Isolated Process • Small binary interface to kernel – threads, memory, & channels “SIP” • Seal the process on execution – no dynamic code loading ABI – no in-process plug-ins • Everything can run in ring 0 in kernel memory! Kernel Singularity SIP safety/isolation • Language safety ensures that untrusted code cannot create or mutate pointers to access the memory pages of another SIP. • SIPs do not share data, so all communications occurs through the exchange of messages over message-passing