The exokernel architecture makes resource management unprivileged but safe by separating management from protection: a protected resource protects resources while untrusted application-level software manages them.
On an exokernel system, OS software becomes: unprivileged, able to co-exist with other implementations, modifiable and deployable. The default socket and file system implementations built on top of XIO perform significantly better than the OpenBSD implementations of the same interfaces. Xok lets libOSes use the software-only bits of page tables, greatly simplifying the implementation of copy on write. Using critical sections instead of locks removes the need to communicate to manage a lock. XN uses these roots to implement common file system operations.
An exokernel is an operating system kernel that allows applications to directly manage and allocate hardware resources. This is different from traditional monolithic or microkernels, which use an intermediary layer. It was introduced in the mid-1990s to improve performance, flexibility, and security.
An exokernel minimizes the role of the kernel in managing system resources. It provides a thin, low-level layer that performs basic resource allocation and protection, and shifts responsibility for high-level abstractions (like files or sockets) to the applications or libraries.
Advantages of exokernels include better performance than traditional kernels, the ability for applications to choose abstractions and resource management policies that suit their needs, and fine-grained access control and resource isolation, making it harder for malicious applications to compromise the system.
However, exokernels have not gained widespread adoption in mainstream operating systems due to various reasons. Developing applications is more complex, as programmers need to handle low-level details that are typically abstracted away by traditional kernels. Applications developed for exokernels are often tightly coupled to the underlying hardware and may not be easily portable across different platforms. There is no widely accepted standard for exokernel design, making it difficult for developers to create reusable libraries and tools.
The ideas and principles of exokernels have influenced the design of other systems, such as unikernels, library operating systems, and virtualization technologies.
Exokernels are a type of operating system kernel that can work on different hardware architectures, such as multicore, NUMA, and MIPS systems. Their aim is to reduce the kernel's role in managing system resources, giving more control to applications that run on top of them. Here's how exokernels work on each of these architectures:
1. Exokernel and Multicore:
Exokernels use multicore processors by allowing applications to manage and allocate resources, such as CPU cores, directly. This reduces overhead caused by traditional kernel abstractions and resource management policies, which can make things faster. With exokernels, applications can choose how to split tasks across cores, balance the workload, and handle synchronization based on their specific needs.
2. Exokernel and NUMA:
NUMA architectures have varying memory access times depending on whether a processor accesses local memory or the memory of another processor. Exokernels give applications more control over memory allocation and management in NUMA systems. By allowing applications to manage memory directly, they can optimize data placement based on their specific access patterns, leading to better performance. Exokernels can also enable more fine-grained control over memory protection and sharing among different applications running on a NUMA system.
3. Exokernel and MIPS:
MIPS is a hardware architecture based on RISC design principles. Exokernels can be implemented on MIPS systems to give applications direct control over hardware resources. By reducing the kernel's role in resource management, exokernels can help applications get the most out of the performance benefits offered by the MIPS architecture.
In summary, exokernels work on different hardware architectures, such as multicore, NUMA, and MIPS systems. By enabling applications to manage resources more directly, exokernels can improve performance, flexibility, and security on these platforms. However, exokernels are not widely used in mainstream operating systems.
-
SPACE is a “submicro-kernel” that provides only low-level kernel abstractions defined by the trap and architecture interface [73]. Its close coupling to the architecture makes it similar in many ways to an exokernel, but we have not been able to make detailed comparisons because its design methodology and performance have not yet been published
-
The SPIN project is building a microkernel system that allows applications to make policy decisions [9] by safely downloading extensions into the kernel. Its close coupling to the architecture makes it similar in many ways to an exokernel, but we have not been able to make detailed comparisons because its design methodology and performance have not yet been published.
-
In addition, our exokernel systems demonstrate that low-level secure multiplexing and library operating systems can offer excellent performance. Like an exokernel, the Cache Kernel [16] provides a low-level kernel that can support multiple applicationlevel operating systems
-
Like an exokernel, the Cache Kernel [16] provides a low-level kernel that can support multiple applicationlevel operating systems. To the best of our knowledge the Cache Kernel and ExOS, the libOS used on three generations of exokernels [25, 48], are the first general-purpose library operating systems implemented in a multiprogramming environment
-
The Nemesis kernel [56, 76] has many similarities to an exokernel, despite a vast difference in goals. In our experience, servers become de facto privileged in that their functionality cannot be overridden by applications.
-
Exokernel implementation of virtual memory, networking, exceptions, and process management have all performed well, without aggressive tuning. In fact, on the first exokernel system we built, Aegis [25], if an exokernel primitive did not perform significantly faster — typically a factor of five to tenfold better — than that of a traditional system from the beginning, we looked for “what was wrong.”
-
Ultrix, despite its poor performance relative to Aegis, is not a poorly tuned system; it is a mature monolithic system that performs quite well in comparison to other operating systems [69]. While Aegis and ExOS do not offer the same level of functionality as Ultrix, we do not expect these additions to cause large increases in our timing measurements.
-
As we demonstrate below, an application can enforce proportional sharing on a collection of sub-processes. Using the Aegis yield primitive and control over time slices, we have built an application-level scheduler that implements stride scheduling [91], a deterministic, proportional-share scheduling mechanism that improves on recent work [90]
-
Hardware differences make comparing our numbers to others in the literature difficult. We attempt an extremely crude comparison of our protected control transfer operation to the equivalent operation on L3 [57], the fastest published result by normalizing the IPC on both systems using SPECint92 rating of Aegis's DEC5000 and L3's 486 (16.1 vs. 30.1)
-
For flexibility and speed an exokernel provides fine-grained protection: i.e., at the level of disk blocks rather than partitions. To do so we must answer the simple question “who can use this block?” Doing so requires constructing a mapping of each disk block to every principal that can use it, which turns out to be quite difficult [48] mainly because it requires building the moral equivalent of a file system
-
While an exokernel allows experimentation with completely different OS interfaces, a more important result may be improving the rate of innovation of implementations of existent interfaces. We also ran the Modified Andrew Benchmark (MAB) [69]
-
When the file cache does not capture the majority of client requests, this extension can improve HTTP throughput by up to a factor of two. Figure 5-2 shows HTTP request throughput as a function of the requested document size for five servers: the NCSA 1.4.2 server [68] running on OpenBSD 2.0, the Harvest cache [14] running on OpenBSD 2.0, the base socket-based server running on OpenBSD 2.0 (i.e., our HTTP server without any optimizations), the base socket-based server running on the Xok exokernel system (i.e., our HTTP server without any optimizations
-
The main benefit of downloaded code is not execution speed, but rather trust and consequently power. While we started with the view that downloading code was useful for speed (e.g., to eliminate the cost of kernel/user boundary crossings) [25] it has turned out to be far more crucial for power: because downloaded code can be controlled, it can be safely granted abilities that external, unrestricted application code cannot
-
The chapter is organized as follows. The next four sections discuss different language-based subsystems, which form the spine for our experiences and lessons: DPF [31], our packet filter engine; application specific message handlers (ASHs) [25, 92, 93], a networking system which invokes downloaded code on message arrival; XN [48], the disk protection subsystem described in Chapter 4, which contains our most interesting use of downloaded code; and finally, protected methods, which applications use to enforce invariants on shared state
-
Packet filters are one of the most successful examples of downloaded code: most modern operating systems provide support for them. This section discusses our packet filter system, DPF (“dynamic packet filters”) [25, 31], which was briefly discussed in Chapter 3
-
Typical systems have many filters simultaneously active, one for each network connection. We made the DPF language declarative, unlike previous packet filter languages [65, 64, 95]
-
Our first real implementation of DPF missed the implications of this transformation. We naively treated the trie as slowly changing code in that we potentially regenerated the entire structure on insertion of a new filter [31]
-
In theory, coupling packet arrival to application semantics is profitable. Separate from our work, Edwards et al [24] provide a way use simple application-provided scripts to direct message placement while Fiuczynski and Bershad [32] provide a fully general messaging system
-
This section briefly discusses our most recent use of downloaded code, protected methods. Similar to [9], we provides them as an extensible means for applications to implement safe decentralized sharing of state in those cases where the kernel's low-level access control is insufficient
-
Tennenhouse and Weatherall have proposed to use mobile code to build Active Networks [86]; in an active network, protocols are replaced by programs, which are safely executed in the operating system on message arrival. Curiously, in contrast to our experience, most uses of mobile code in an Active Network seem to be to improve efficiency, rather increase power
An [exokernel](https://en.wikipedia.org/wiki/Exokernel) is an operating system kernel that allows applications to directly manage and allocate hardware resources. This is different from traditional [monolithic](https://en.wikipedia.org/wiki/Monolithic_kernel) or [microkernels](https://en.wikipedia.org/wiki/Microkernel), which use an intermediary layer. It was introduced in the mid-1990s to improve performance, flexibility, and security.
An exokernel minimizes the role of the kernel in managing system resources. It provides a thin, low-level layer that performs basic resource allocation and protection, and shifts responsibility for high-level abstractions (like files or sockets) to the applications or libraries.
Advantages of exokernels include:
1. Better performance than traditional kernels.
2. Applications can choose abstractions and resource management policies that suit their needs.
3. Fine-grained access control and resource isolation, making it harder for malicious applications to compromise the system.
However, exokernels have not gained widespread adoption in mainstream operating systems due to various reasons:
1. Developing applications is more complex, as programmers need to handle low-level details that are typically abstracted away by traditional kernels.
2. Applications developed for exokernels are often tightly coupled to the underlying hardware, and may not be easily portable across different platforms.
3. There is no widely accepted standard for exokernel design, making it difficult for developers to create reusable libraries and tools.
The ideas and principles of exokernels have influenced the design of other systems, such as [unikernels](https://en.wikipedia.org/wiki/Unikernel) , [library operating systems](https://en.wikipedia.org/wiki/Library_operating_system), and [virtualization technologies](https://en.wikipedia.org/wiki/Virtualization).