Exokernel: An Operating System Architecture for Application-Level Resource Management

Abstract

📜 Abstract

Traditional operating systems limit the performance, flexibility, and functionality of applications by fixing the interface and implementation of operating system abstractions such as interprocess communication and virtual memory. The exokernel operating system architecture addresses this problem by providing application-level management of physical resources. In the exokernel architecture, a small kernel securely exports all hardware resources through a low-level interface to untrusted library operating systems. Library operating systems use this interface to implement system objects and policies. This separation of resource protection from management allows application-specific customization of traditional operating system abstractions by extending, specializing, or even replacing libraries. We have implemented a prototype exokernel operating system. Measurements show that most primitive kernel operations (such as exception handling and protected control transfer) are ten to 100 times faster than in Ultrix, a mature monolithic UNIX operating system. In addition, we demonstrate that an exokernel allows applications to control machine resources in ways not possible in traditional operating systems. For instance, virtual memory and interprocess communication abstractions are implemented entirely within an application-level library. Measurements show that application-level virtual memory and interprocess communication primitives are five to 40 times faster than Ultrix’s kernel primitives. Compared to state-of-the-art implementations from the literature, the prototype exokernel system is at least five times faster on operations such as exception dispatching and interprocess communication.

Description

✨ Summary

The paper proposes the exokernel architecture, which minimizes the trusted kernel and moves the implementation of conventional operating-system abstractions into untrusted, application-level library operating systems. Instead of providing fixed abstractions such as processes, virtual memory, files, and interprocess communication, the kernel securely multiplexes physical resources and exposes them through low-level interfaces. Applications or library operating systems then implement the abstractions and policies most appropriate for their workloads. The central design objective is to separate protection from resource management: the kernel enforces ownership and isolation without needing to understand higher-level resource semantics. (pages.cs.wisc.edu)

The authors identify three mechanisms for achieving this separation. Secure bindings associate applications with resources and allow efficient access checks after authorization has occurred. Visible revocation informs application-level software when resources must be reclaimed, allowing it to choose what to release and update its own state. An abort protocol allows the kernel to forcibly break bindings when an application fails to respond. Secure bindings may be implemented with hardware mechanisms, cached software structures, or safe application code downloaded into the kernel. The prototype uses capabilities for memory protection, a software translation-lookaside buffer, dynamically compiled packet filters, and application-specific safe handlers for latency-sensitive network processing. (pages.cs.wisc.edu)

The prototype consists of the Aegis exokernel and the ExOS library operating system. Aegis exports processor time, physical memory, address translation, exceptions, interrupts, and network access. ExOS implements processes, virtual memory, interprocess communication, network protocols, and other higher-level services in application address spaces. This organization allows applications to replace or specialize components without modifying the kernel. Demonstrated examples include application-level pipes, shared-memory communication, lightweight remote procedure calls, configurable page-table structures, trusted RPC variants, and an application-level stride scheduler. (pages.cs.wisc.edu)

The experimental results support the authors’ main claims, subject to the limitations of a research prototype and best-case microbenchmark methodology. Aegis provides substantially faster exception dispatch, protected control transfer, and system-call paths than Ultrix on the tested DECstation hardware. ExOS provides faster IPC and several virtual-memory operations while adding little overhead to a conventional matrix-multiplication workload. Dynamically generated packet filters and application-specific safe handlers reduce network-processing and round-trip latency, particularly when receiver-side scheduling would otherwise delay responses. The results show that application-level operating-system services can be both efficient and customizable when the underlying kernel interface is sufficiently low-level. (pages.cs.wisc.edu)

The work directly led to subsequent Aegis-derived Xok/ExOS research. Later experiments reported that Xok/ExOS could run many unmodified UNIX applications with performance comparable to mature monolithic systems while retaining application-level control over operating-system services. (pdos.csail.mit.edu)

The library-operating-system model also influenced later systems research. Corey explicitly adopted an exokernel-like organization and library operating systems to let applications control sharing and experiment with alternative mechanisms on multicore systems. (static.usenix.org) OSv described its hypervisor as playing an exokernel-like role and its per-VM operating-system instance as a library OS, applying the model to single-application cloud virtual machines. (usenix.org) More recently, BPF for Storage explicitly identified itself as an exokernel-inspired approach, using user-defined code inside the storage path to reduce kernel-layer overhead while retaining protection and resource-translation mechanisms. (cs.columbia.edu)