Hubbry Logo
ExokernelExokernelMain
Open search
Exokernel
Community hub
Exokernel
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Exokernel
Exokernel
Exokernel
View on Wikipedia
from Wikipedia
Graphic overview of Exokernel. Exokernels are much smaller than a normal kernel (monolithic kernel). They give more direct access to the hardware, thus removing most abstractions

Exokernel is an operating system kernel developed by the MIT Parallel and Distributed Operating Systems group,[1] and also a class of similar operating systems.

Operating systems generally present hardware resources to applications through high-level abstractions such as (virtual) file systems. The idea behind exokernels is to force as few abstractions as possible on application developers, enabling them to make as many decisions as possible about hardware abstractions.[2] Exokernels are tiny, since functionality is limited to ensuring protection and multiplexing of resources, which is considerably simpler than conventional microkernels' implementation of message passing and monolithic kernels' implementation of high-level abstractions.

Implemented abstractions are called library operating systems; they may request specific memory addresses, disk blocks, etc. The kernel only ensures that the requested resource is free, and the application is allowed to access it. This low-level hardware access allows the programmer to implement custom abstractions, and omit unnecessary ones, most commonly to improve a program's performance. It also allows programmers to choose what level of abstraction they want, high, or low.

Exokernels can be seen as an application of the end-to-end principle to operating systems, in that they do not force an application program to layer its abstractions on top of other abstractions that were designed with different requirements in mind. For example, in the MIT Exokernel project, the Cheetah web server stores preformatted Internet Protocol packets on the disk, the kernel provides safe access to the disk by preventing unauthorized reading and writing, but how the disk is abstracted is up to the application or the libraries the application uses.

Motivation

[edit]

Traditionally, kernel designers have sought to make individual hardware resources invisible to application programs by requiring the programs to interact with the hardware via some abstraction model. These models include file systems for disk storage, virtual address spaces for memory, schedulers for task management, and sockets for network communication. These abstractions of the hardware make it easier to write programs in general, but limit performance and stifle experimentation in new abstractions. A security-oriented application might need a file system that does not leave old data on the disk, while a reliability-oriented application might need a file system that keeps such data for failure recovery.

One option is to remove the kernel completely and program directly to the hardware, but then the entire machine would be dedicated to the application being written (and, conversely, the entire application codebase would be dedicated to that machine). The exokernel concept is a compromise: let the kernel allocate the basic physical resources of the machine (e.g. disk blocks, memory pages, and processor time) to multiple application programs, and let each program decide what to do with these resources. The program can then link to a support library that implements the abstractions it needs (or it can implement its own).

MIT exokernels

[edit]

MIT developed two exokernel-based operating systems, using two kernels: Aegis, a proof of concept with limited support for storage, and XOK, which applied the exokernel concept more thoroughly.

An essential idea of the MIT exokernel system is that the operating system should act as an executive for small programs provided by the application software, which are constrained only by the requirement that the exokernel must be able to guarantee that they use the hardware safely.

Design

[edit]

The MIT exokernel manages hardware resources as follows:

Processor
The kernel represents the processor resources as a timeline from which programs can allocate intervals of time. A program can yield the rest of its time slice to another designated program. The kernel notifies programs of processor events, such as interrupts, hardware exceptions, and the beginning or end of a time slice. If a program takes a long time to handle an event, the kernel will penalize it on subsequent time slice allocations; in extreme cases the kernel can abort the program.
Memory
The kernel allocates physical memory pages to programs and controls the translation lookaside buffer. A program can share a page with another program by sending it a capability to access that page. The kernel ensures that programs access only pages for which they have a capability.
Disk storage
The kernel identifies disk blocks to the application program by their physical block address, allowing the application to optimize data placement. When the program initializes its use of the disk, it provides the kernel with a function that the kernel can use to determine which blocks the program controls. The kernel uses this callback to verify that when it allocates a new block, the program claims only the block that was allocated in addition to those it already controlled.
Networking
The kernel implements a programmable packet filter, which executes programs in a bytecode language designed for easy security-checking by the kernel.

Applications

[edit]

The available library operating systems for the exokernel include the custom ExOS system and an emulator for BSD. In addition to these, the exokernel team created the Cheetah web server, which uses the kernel directly.

History

[edit]
The Architecture of MINIX 3

The exokernel concept has been around since at least 1994,[3] but as of 2024 exokernels are still a research effort and have not been used in any major commercial operating systems.

Another concept operating exokernel system is Nemesis, written by University of Cambridge, University of Glasgow, Citrix Systems, and the Swedish Institute of Computer Science. MIT has also built several exokernel-based systems, including ExOS.

See also

[edit]

References

[edit]

Bibliography

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Exokernel

View on Grokipedia
from Grokipedia
An exokernel is an operating system architecture that minimizes the role of the kernel by securely exporting raw hardware resources through low-level interfaces, enabling untrusted library operating systems to implement customized abstractions and manage resources directly at the application level. This design, proposed in 1995 by Dawson R. Engler, M. Frans Kaashoek, and James O'Toole at MIT, addresses limitations in traditional kernels, which impose fixed abstractions like files and processes that hinder performance and flexibility. The exokernel itself handles only protection mechanisms—such as secure bindings to map resource names to physical hardware, visible resource revocation, and abort protocols—while delegating all policy decisions and higher-level services to application-specific library OSes (libOSes). Key advantages include significantly improved efficiency, with prototype implementations demonstrating kernel operations 10-100 times faster than contemporary systems like , and application-level mechanisms such as and achieving 5-40 times better performance. For instance, exception dispatching in the exokernel took 1.5 µs compared to 130-238 µs in , and IPC latencies ranged from 5.7-30.9 µs versus 118-326 µs. The architecture was prototyped as the exokernel and ExOS libOS on MIPS-based DECstations, incorporating techniques like dynamic code generation for packet filters and hardware-supported secure bindings via TLB entries. While influential in exploring application-controlled , exokernels prioritize raw hardware access over conventional usability, influencing later research in extensible and systems.

Fundamentals

Definition and Principles

An exokernel is a type of operating kernel designed to minimize the role of the kernel in by providing only the essential mechanisms for protecting hardware resources and access among multiple applications, while avoiding the imposition of high-level abstractions such as files, processes, or . Instead of enforcing specific policies or interfaces, the exokernel exports raw hardware resources directly to applications through a low-level interface, allowing applications to manage these resources according to their own needs. This architecture shifts the implementation of operating services from the kernel to user-space libraries, enabling greater flexibility and efficiency tailored to individual applications. The core principles of an exokernel revolve around secure without compromising protection. Central to this is the use of secure bindings, often implemented via capabilities, which are unforgeable tokens that authorize access to specific resources while decoupling the authorization from the actual usage, such as through hardware-assisted mechanisms like TLB entries or packet filters. Applications implement their own abstractions and policies through library operating systems (LibOS), which are untrusted code libraries linked directly to applications, handling tasks like scheduling, communication, and at the application level. This design maintains a clear distinction between the kernel's role in protecting hardware access—ensuring isolation and preventing interference among applications—and the untrusted application code that performs the actual . Key examples illustrate these principles in action. For processor management, the exokernel multiplexes using secure timers and a linear vector structure to implement time slicing, such as , while granting applications control over context switching without kernel intervention. In memory management, the exokernel protects physical pages using hardware page tables but delegates allocation, deallocation, and mapping decisions to the application's LibOS, which can customize virtual-to-physical translations via capabilities for optimal performance. These mechanisms ensure that while the kernel enforces security, applications retain full authority over how resources are utilized.

Comparison to Other Kernel Architectures

Exokernels differ fundamentally from monolithic kernels, such as , where all operating system services—including device drivers, file systems, and networking stacks—are implemented within a single, large in kernel mode. This design enables high performance through direct function calls and but results in reduced , as modifications to one component can destabilize the entire kernel. In contrast, exokernels offload nearly all abstractions and management to user-space library operating systems (libOSes), retaining only a minimal kernel for secure resource multiplexing, which enhances customization by allowing applications to implement tailored interfaces without kernel modifications. For instance, while a monolithic kernel enforces uniform abstractions like files and processes, an exokernel exposes raw hardware resources, enabling specialized implementations that can achieve up to 100 times faster exception dispatching compared to systems like . Compared to microkernels, exemplified by Mach, exokernels extend the minimalism further by eschewing even the basic abstractions that microkernels typically impose, such as message-passing IPC or models enforced at the kernel level. Microkernels run most services in user space for improved modularity and fault isolation but still mediate resource access through fixed interfaces, limiting application control over hardware. Exokernels avoid such mediation by using secure bindings to grant applications direct, protected access to resources, thereby supporting greater flexibility; for example, libOSes can implement custom page tables or communication primitives without kernel involvement. Performance benchmarks on exokernel prototypes demonstrate 5 to 40 times faster than microkernel-based systems, due to reduced context-switching overhead. Hybrid kernels, like , blend elements of monolithic and designs by executing core services in kernel space for efficiency while allowing some user-space drivers and . This approach aims to balance with reliability but retains significant abstraction layers, such as standardized APIs for I/O and , which constrain customization compared to exokernels. Exokernels prioritize protection without these layers, exporting hardware directly to untrusted libOSes, which can lead to more efficient resource use but demands robust application-level safeguards. Unlike hybrids, which may incur overhead from partial user-space mediation, exokernels minimize kernel code, potentially outperforming them in specialized workloads like high-throughput networking. The primary trade-offs of exokernels lie in their emphasis on flexibility at the cost of increased developer responsibility: while they enable high and customization through user-space management, they require applications to implement reliable libOSes, potentially complicating development for general-purpose software. Monolithic and hybrid kernels simplify programming with pre-defined abstractions but limit adaptability, whereas microkernels offer better isolation yet introduce communication overhead. Exokernels thus occupy a unique niche, excelling in environments demanding tailored resource control, such as high-performance servers.
Kernel TypeAbstraction LevelProtection ScopePerformance ImplicationsExamples
MonolithicHigh (e.g., files, processes)Centralized in kernel spaceHigh throughput via direct calls; prone to crashes
MicrokernelLow to moderate (e.g., IPC primitives)User-space services with kernel mediationLower due to ; better modularityMach
HybridModerate (blended APIs)Kernel space for core, user space for someBalanced; avoids full microkernel overhead
ExokernelMinimal (raw hardware)Secure bindings for direct accessSuperior for specialized apps; requires libOSesMIT XOK

Motivation

Performance and Efficiency Goals

The primary performance goal of an exokernel is to minimize kernel overhead by offloading high-level abstractions to application-specific library operating systems (LibOSes), thereby reducing the frequency and cost of switches and trap handling. In traditional monolithic or designs, the kernel enforces uniform abstractions that introduce unnecessary indirection and processing for every system interaction, leading to slower execution paths. By contrast, exokernels provide only low-level mechanisms for resource protection, allowing applications to implement tailored abstractions directly, which can make primitive operations 10 to 100 times faster than those in systems like . This approach decouples protection from management, ensuring that the kernel's role is limited to verifying secure bindings rather than mediating every resource access, ultimately accelerating overall application performance. Efficiency in resource utilization is another key objective, achieved through direct hardware access that enables optimized data paths without kernel intervention. For instance, in network I/O, applications can bind directly to hardware interfaces, avoiding the latency of kernel-mediated packet processing and buffering, which often bloats traditional kernels with "one-size-fits-all" mechanisms unsuitable for diverse workloads. This direct access supports customized resource multiplexing, where LibOSes can implement application-specific optimizations, such as specialized scheduling or caching, to maximize throughput. Early evaluations indicate that such designs can yield performance gains of up to 10 times in I/O-bound tasks compared to conventional kernels, primarily by eliminating overhead in management and (IPC). To illustrate the overhead reduction conceptually, consider the syscall paths: Traditional Kernel Path:
  • Application request → Kernel trap → Abstraction enforcement (e.g., semantics) → Hardware access → Return through kernel layers.
Exokernel Path:
  • Application request → Secure binding check (minimal kernel involvement) → Direct hardware access via LibOS → Optimized return.
This streamlined path reduces latency in critical operations, such as exception dispatching, which is up to 5 times faster in exokernels than in optimized traditional implementations. By avoiding generalized abstractions that impose uniform policies, exokernels prevent performance penalties from mismatched resource handling, fostering higher efficiency across varied application domains.

Flexibility and Customization Benefits

Exokernels enable significant flexibility by allowing applications to implement customized operating systems (LibOSes) that provide domain-specific abstractions tailored to particular workloads. For instance, a application might use a LibOS with real-time scheduling mechanisms to ensure low-latency processing, while a database system could employ one optimized for with fine-grained to handle large-scale queries efficiently. This approach contrasts with traditional kernels, where fixed abstractions impose uniform behaviors unsuitable for diverse needs. The use of LibOSes facilitates in operating system design by permitting developers to experiment with new features without modifying kernel, thus avoiding system-wide disruptions and enabling incremental improvements. Furthermore, these abstractions gain portability across hardware platforms, as LibOS implementations can be adapted independently of the underlying exokernel, reducing the compatibility issues common in monolithic systems. A key enabler of this customization is the exokernel's secure exposure of low-level hardware interfaces, which allows applications to optimize directly for specific workloads without compromising integrity. For example, a LibOS might incorporate custom packet handling routines to streamline HTTP traffic processing, differing markedly from a general-purpose LibOS that prioritizes broad compatibility over specialized efficiency. This secure binding of resources to applications minimizes overhead and empowers precise control, fostering adaptability in evolving computing environments.

Design

Resource Protection and Multiplexing

Exokernels achieve resource protection by implementing secure bindings that associate resource names with physical hardware, ensuring isolation among mutually distrustful applications without imposing high-level abstractions. These bindings are verified by the kernel at allocation time, allowing applications to manage resources directly while the kernel enforces ownership and access rights. This minimal intervention separates protection mechanisms from policy decisions, enabling application-specific optimizations. The primary protection primitives in exokernels are capabilities, which serve as self-authenticating tokens granting fine-grained ownership and access to hardware resources. For , page capabilities bind virtual addresses to physical pages, leveraging hardware address translation like the TLB to enforce without kernel-mediated virtual management. Similarly, block capabilities secure disk resources, permitting applications to handle allocation, caching, and I/O scheduling independently while the kernel prevents unauthorized access. These capabilities support , allowing applications to securely transfer rights to other entities without kernel involvement. Multiplexing of resources in exokernels occurs through low-level, hardware-assisted techniques that avoid traditional kernel abstractions. For CPU time-sharing, secure clocks use timer interrupts to allocate time slices in a verifiable manner, with applications controlling context switches and the kernel tracking excess usage via counters to prevent monopolization. Memory is space-shared by caching bindings in a software TLB, enabling direct physical access and reducing overhead compared to full kernel translation. Network resources are multiplexed using programmable packet filters, which compile application-specific code to classify and dispatch packets efficiently, such as achieving TCP/IP demultiplexing in 1.5 microseconds on prototype hardware. The security model of exokernels relies on the kernel's role as a trusted verifier rather than an interpreter of resource usage, ensuring bindings are secure but leaving management to untrusted library operating systems. Revocation is handled through visible protocols, where the kernel notifies resource owners of deallocation requests, and an abort mechanism forcibly terminates non-cooperative bindings to maintain system integrity. Interrupts and traps are processed minimally by the kernel, which dispatches them directly to application handlers in approximately 1.5 microseconds using just 18 instructions, thereby minimizing latency and preserving application control.

Library Operating Systems Integration

In exokernel architectures, library operating systems (LibOSes) serve as untrusted, user-level libraries that implement traditional operating system abstractions, such as file systems, management, and scheduling, directly atop the exokernel's low-level hardware primitives. These LibOSes enable applications to access and manage resources without the overhead of kernel-mediated abstractions, allowing for tailored implementations that optimize performance for specific workloads. The integration model positions LibOSes as components linked directly into the application's , transforming traditional system calls into efficient library function calls and minimizing context switches to the kernel. This approach supports the coexistence of multiple LibOSes on the same system, where different applications can employ distinct LibOS variants—such as one emulating interfaces for legacy software and another providing specialized networking stacks—fostering customization without global interference. Building upon the exokernel's resource capabilities for secure multiplexing, LibOSes request and manage hardware resources like or disk blocks through protected interfaces. Key challenges in LibOS integration include ensuring compatibility across diverse applications and maintaining isolation between coexisting LibOS instances to prevent faults from propagating. Compatibility is addressed by designing LibOSes to emulate standard interfaces, such as UNIX APIs, and supporting dynamic linking for shared components that can be loaded at runtime. Isolation relies on exokernel-enforced mechanisms like secure capabilities and abort protocols, which revoke access or terminate faulty operations without compromising system-wide , while of LibOS modules—via techniques like application-specific handlers—allows for modular extensions without full recompilation. A prominent example is ExOS, a LibOS developed for exokernel prototypes such as and Xok, which provides familiar abstractions including processes with fork semantics, via , and file systems using low-level disk access primitives. ExOS links directly with applications to deliver these interfaces while permitting custom optimizations, such as application-specific scheduling or I/O handling, thereby balancing portability for unmodified UNIX programs like compilers and shells with opportunities for specialized enhancements.

Implementations

MIT Exokernels

The MIT exokernel project, led by researchers at the MIT Laboratory for Computer Science, produced two key prototypes: and XOK. These implementations demonstrated the feasibility of the exokernel architecture by securely exporting hardware resources to untrusted library operating systems (LibOSes) while minimizing kernel abstractions. Aegis, developed in the mid-1990s, served as an initial proof-of-concept exokernel targeted at MIPS-based DECstations. It focused on protecting core resources including the processor (via time-slices at clock granularity), physical memory (with fine-grained page allocation), and limited disk support through physical block naming and allocation. Aegis employed capabilities for secure resource access and visible revocation mechanisms to ensure safety without high-level abstractions, enabling applications to implement custom management directly. The kernel's small footprint highlighted the approach's efficiency, with components like its stride scheduler implemented in under 100 lines of code. Performance evaluations showed significant reductions in overhead, such as exception dispatch in 1.5 microseconds (five times faster than the best reported systems and 100 times faster than ) and protected control transfers in 1.4 microseconds. XOK, an evolution of from the late 1990s, extended the design to x86 PC hardware and added comprehensive support for disk (via the XN subsystem with user-defined formats for metadata) and networking. It facilitated running multiple LibOS instances simultaneously, allowing specialized for diverse applications on shared hardware. Key features included capabilities for all resources to enforce and dynamic packet filters for secure network multiplexing, where applications could register filters to handle specific packet types like TCP port 80 without kernel mediation. These mechanisms reduced I/O overhead substantially; for instance, via ExOS pipes achieved latencies of 14.2 microseconds, ten times faster than Ultrix equivalents. XOK's design emphasized safety through techniques like secure bindings and abort protocols, preventing interference among LibOSes. The ExOS LibOS, implemented to run atop both and XOK, provided a user-level, extensible interface with BSD compatibility, enabling unmodified applications such as gcc, , and to execute efficiently. ExOS managed abstractions like (in about 1,000 lines of code) and file systems at the application level, outperforming traditional systems in I/O-bound tasks. A notable demonstration was the web server, a specialized LibOS that stored preformatted IP packets on disk for direct hardware access; it achieved up to eight times the throughput of the best UNIX HTTP servers (e.g., 29.3 MB/s versus 16.5 MB/s for socket-based implementations on ) on the same hardware, particularly for small documents. These results underscored the exokernel's potential for high-performance, customized environments without compromising .

Other Exokernel Projects

One prominent exokernel-inspired project is , developed in the late 1990s by researchers at the , , Swedish Institute of Computer Science, and as part of the Pegasus project. Nemesis features a minimal kernel that provides fine-grained resource ownership and guarantees for CPU, memory, network, and disk bandwidth, allowing applications to manage these resources directly while implementing operating system services in user-space shared libraries. It emphasizes efficient communication subsystems through a single design that reduces context switches and data copying, particularly for multimedia and time-sensitive applications, with fast (IPC) mechanisms to support low-latency interactions. Another related effort is , an extensible developed at the in the mid-1990s, which enables applications to link custom code directly into the kernel for specialized services. Unlike pure exokernel designs that push abstractions entirely to user-space library operating systems (LibOS), SPIN focuses on safe kernel extensions via a protected event-driven mechanism, allowing dynamic adaptation for performance-critical tasks such as protocol stacks or scheduling policies. This approach demonstrated improved efficiency in application-specific scenarios, such as network processing, through measured reductions in overhead compared to traditional monolithic kernels. Post-2000 research prototypes have explored exokernel concepts in modern contexts, including XOmB, a 64-bit, multicore exokernel developed by students at the starting around 2010, which leverages large virtual address spaces and for hardware resource management to support flexible application-level abstractions on contemporary x86 architectures. Influences of exokernel principles also appear in unikernel systems like MirageOS, a OS framework from the initiated in 2013, where applications compile directly into specialized kernels for cloud and virtualized environments, emphasizing minimalism and resource customization without traditional OS layers. As of 2025, these remain primarily academic or experimental efforts, with no widespread commercial adoptions, though they inform embedded and research for efficiency in resource-constrained settings.

History and Impact

Origins and Early Development

The exokernel concept originated in the mid-1990s at the Massachusetts Institute of Technology (MIT), specifically within the Parallel and Distributed Operating Systems (PDOS) group in the Laboratory for Computer Science (LCS), now part of the Computer Science and Artificial Intelligence Laboratory (CSAIL). The architecture was first proposed around 1994 as a response to the limitations of existing operating system designs, particularly the performance overhead and inflexibility of microkernels, which enforced high-level abstractions that hindered application-specific optimizations. This dissatisfaction stemmed from observations that traditional kernels, including microkernels, blurred the separation between protection mechanisms and policy decisions, leading to unnecessary mediation and reduced efficiency for diverse workloads. The foundational ideas were formally outlined in the 1995 paper "Exokernel: An Operating System Architecture for Application-Level Resource Management" by Dawson R. Engler, M. Frans Kaashoek, and James O'Toole Jr., presented at the Tenth ACM Symposium on Operating Systems Principles (SOSP). This work introduced the core principles of exokernels: a minimal kernel that securely multiplexes hardware resources while delegating all higher-level management to untrusted library operating systems running in application space. The paper emphasized how this approach could achieve near-hardware performance by avoiding kernel-enforced abstractions, drawing on hardware capabilities for secure . Early development progressed through prototypes funded in part by the Defense Advanced Research Projects Agency (). The first implementation, , served as a proof-of-concept exokernel for MIPS-based DECstations, demonstrating basic resource protection and multiplexing with an accompanying library OS called ExOS; it was developed around 1995–1996 as part of the initial research efforts. By 1997, the project evolved to XOK, a more comprehensive exokernel that extended these ideas with broader hardware support and application-level abstractions, as detailed in a follow-up SOSP paper. This timeline reflected ongoing collaborations within the MIT PDOS group, building on the 1995 framework to refine secure, low-level interfaces.

Research Influence and Modern Relevance

The exokernel architecture has profoundly shaped subsequent in extensible operating systems by pioneering the separation of resource protection from high-level abstractions, enabling untrusted library operating systems (LibOSes) to manage hardware directly while the kernel enforces . This approach influenced the development of , which compile applications with only the necessary OS components into a single address space, reducing overhead and improving performance in specialized environments; early unikernel designs trace their roots to exokernel's late-1990s emphasis on application-level resource control. Similarly, exokernel concepts have informed advancements in container technologies, where projects like X-Containers adopt a minimal exokernel-like kernel paired with per-container LibOSes to enhance isolation and performance in cloud-native settings, echoing Docker's user-space execution model but with stronger hardware multiplexing for multi-tenant workloads. In modern contexts, exokernel principles remain relevant for resource-constrained domains such as IoT and , where custom resource management via LibOSes allows tailored handling of sensors and networks to minimize latency and power usage. However, challenges persist in multi-tenant environments, as the exokernel's low-level exposure demands robust revocation and attestation mechanisms to prevent interference, a concern addressed in datacenter-oriented designs like and IX that build on exokernel multiplexing for safe sharing. As of 2025, exokernel traits are gaining traction in through exokernel-inspired microkernels that enable confidential execution in virtual machines, reducing bases for fine-grained function isolation, and in hardware accelerators where direct GPU access via LibOSes bypasses kernel mediation to accelerate data transfers in high-performance workloads. Despite this, widespread adoption has been limited by the complexity of designing secure exokernel interfaces that balance application freedom with protection, requiring LibOS developers to implement device-specific logic that traditional kernels abstract away. Ongoing focuses on improving LibOS and in exokernel systems for critical applications.

References

  1. https://pdos.csail.mit.edu/6.828/2008/readings/engler95exokernel.pdf
  2. https://www.sigarch.org/leave-your-os-at-home-the-rise-of-library-operating-systems/
  3. https://dl.acm.org/doi/10.1145/224057.224076
  4. https://www.cs.utexas.edu/~dahlin/Classes/GradOS/papers/kaashoek97sosp.pdf
  5. https://arxiv.org/pdf/1209.4600
  6. https://pdos.csail.mit.edu/papers/exo-sosp97/exo-sosp97.html
  7. https://web.stanford.edu/~engler/exo-tocs.pdf
  8. https://pages.cs.wisc.edu/~bart/736/papers/exo-sosp95.pdf
  9. https://users.ece.cmu.edu/~ganger/papers/exo-sosp97/exo-sosp97.pdf
  10. https://dspace.mit.edu/bitstream/handle/1721.1/41351/34889746-MIT.pdf
  11. https://pdos.csail.mit.edu/papers/exo:tocs.pdf
  12. http://dspace.mit.edu/bitstream/handle/1721.1/16713/42430053-MIT.pdf
  13. https://www.cl.cam.ac.uk/research/srg/netos/projects/archive/nemesis/
  14. https://dl.acm.org/doi/10.1145/191525.191537
  15. https://www.usenix.org/legacy/events/osdi99/full_papers/hand/hand.pdf
  16. http://people.eecs.berkeley.edu/~kubitron/courses/cs262a-F19/handouts/papers/spin-sosp95.pdf
  17. https://sol.sbc.org.br/index.php/wso/article/download/34552/34343
  18. https://queue.acm.org/detail.cfm?id=2566628
  19. https://dspace.mit.edu/handle/1721.1/16713
  20. https://cacm.acm.org/practice/unikernels/
  21. https://research.redhat.com/blog/article/creating-a-linux-based-unikernel/
  22. https://dl.acm.org/doi/10.1145/3297858.3304016
  23. https://www.csl.cornell.edu/~delimitrou/papers/2019.asplos.xcontainer.pdf
  24. https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-peter.pdf
  25. https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-belay.pdf
  26. https://www.usenix.org/system/files/conference/usenixsecurity25/sec25cycle1-prepub-121-shi-jiacheng.pdf
  27. https://hotcarbon.org/assets/2022/pdf/hotcarbon22-sharma.pdf
  28. https://sites.cs.ucsb.edu/~rich/class/cs270/papers/dawson-exokernel.pdf
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.