Exokernel: An Operating System Architecture forApplication-Level Resource ManagementDawson R. Engler, M. Frans Kaashoek, and James O’Toole Jr.M.I.T. Laboratory for Computer ScienceCambridge, MA 02139, U.S.Aengler, kaashoek , james @lcs.mit.eduTraditional operating systems limit the performance, flexibility, andfunctionality of applications by fixing the interface and implemen-tation of operating system abstractions such as interprocess com-munication and virtual memory. The exokernel operating systemarchitecture addresses this problem by providing application-levelmanagement of physical resources. In the exokernel architecture, asmall kernel securely exports all hardware resources through a low-level interface to untrusted library operating systems. Library op-erating systems use this interface to implement system objects andpolicies. This separation of resource protection from managementallows application-specific customization of traditional operatingsystem abstractions by extending, specializing, or even replacinglibraries.We have implemented a prototype exokernel operating system.Measurements show that most primitive kernel operations (suchas exception handling and protected control transfer) are ten to 100times faster than in Ultrix, a mature monolithic UNIX operating sys-tem. In addition, we demonstrate that an exokernel allows applica-tions to control machine resourcesin ways not possible in traditionaloperating systems. For instance, virtual memory and interprocesscommunication abstractions are implemented entirely within anapplication-level library. Measurements show that application-levelvirtual memory and interprocess communication primitives are fiveto 40 times faster than Ultrix’s kernel primitives. Compared tostate-of-the-art implementations from the literature, the prototypeexokernel system is at least five times faster on operations such asexception dispatching and interprocess communication.Operating systems define the interface between applications andphysical resources. Unfortunately, this interface can significantlylimit the performance and implementation freedom of applications.Traditionally, operating systems hide information about machineresources behind high-level abstractions such as processes, files,address spaces and interprocess communication. These abstrac-tions define a virtual machine on which applications execute; theirimplementation cannot be replaced or modified by untrusted appli-cations. Hardcoding the implementations of these abstractions isThis research was supported in part by the Advanced Research Projects Agency undercontract N00014-94-1-0985and by a NSF National Young Investigator Award.Copyrightc1995 by the Association for Computing Machinery, Inc. Permissionto make digital or hard copies of part or all of this work for personal or classroom useis granted without fee provided that copies are not made or distributed for profit orcommercial advantage and that new copies bear this notice and the full citation on thefirst page. Copyrights for components of this WORK owned by others than ACM mustbe honored. Abstracting with credit is permitted.To copy otherwise, to republish, to post on servers or to redistribute to lists, requiresprior specific permission and/or a fee. Request Permissions from Publications Dept,ACM Inc., Fax +1 (212) 869-0481, [email protected] .inappropriate for three main reasons: it denies applications the ad-vantages of domain-specific optimizations, it discourages changesto the implementations of existing abstractions, and it restricts theflexibility of application builders, since new abstractions can onlybe added by awkward emulation on top of existing ones (if they canbe added at all).We believe these problems can be solved through application-level (i.e., untrusted) resource management. To this end, we havedesigned a new operating system architecture, exokernel, in whichtraditional operating system abstractions, such as virtual memory(VM) and interprocess communication (IPC), are implemented en-tirely at application level by untrusted software. In this architecture,a minimal kernel—which we call an exokernel—securely multi-plexes available hardware resources. Library operating systems,working above the exokernel interface, implement higher-level ab-stractions. Application writers select libraries or implement theirown. New implementations of library operating systems are incor-porated by simply relinking application executables.Substantial evidence exists that applications can benefit greatlyfrom having more control over how machine resources are usedto implement higher-level abstractions. Appel and Li [5] reportedthat the high cost of general-purpose virtual memory primitivesreduces the performance of persistent stores, garbage collectors, anddistributed shared memory systems. Cao et al. [10] reported thatapplication-level control over file caching can reduce applicationrunning time by 45%. Harty and Cheriton [26] and Krueger etal. [30] showed how application-specific virtual memory policiescan increase application performance. Stonebraker [47] arguedthat inappropriate file-system implementation decisions can have adramatic impact on the performance of databases. Thekkath andLevy [50] demonstrated that exceptions can be made an order ofmagnitude faster by deferring signal handling to applications.To provide applications control over machine resources, an ex-okernel defines a low-level interface. The exokernel architecture isfounded on and motivated by a single, simple, and old observation:the lower the level of a primitive, the more efficiently it can beimplemented, and the more latitude it grants to implementors ofhigher-level abstractions.To provide an interface that is as low-level as possible (ideally,just the hardware interface), an exokernel designer has a singleoverriding goal: to separate protection from management. Forinstance, an exokernel should protect framebuffers without under-standing windowing systems and disks without understanding filesystems. One approach is to give each application its own virtualmachine [17]. As we discuss in Section 8, virtual machines canhave severe performance penalties. Therefore, an exokernel uses adifferent approach: it exports hardware resources rather than emu-lating them, which allows an efficient and simple implementation.An exokernel employs three techniques to export resources securely.First, by using secure bindings, applications can securely bind