< Exokernel

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

Dawson R. Engler, M. Frans Kaashoek, and James O'Toole Jr .
Notes by Yin Zhang

Problem with Traditional OS

Too general! Limiting performance, flexibility and functionality by fixing the interface and implementation of OS abstractions like IPC, VM in the kernel.

Exokernel's Approach

Separate resource management from protection. Kernel is only responsible for protection. Traditional abstractions are implemented entirely at application level by library operating systems.

Challenge

To give library operating systems maximum freedom in managing hardware resources while protecting them from each other.

Major tasks

Tracking ownership of resources

Ensuring protection by guarding all resource usage or binding points

Revoking access to resources

Major techniques

Secure bindings

Perform authorization only at bind time. At access time, kernel only needs to implement access check without understanding them.

Implementation techniques

Hardware support. E.g. capability support in hardware.
Software caching. E.g. STLB
Downloading code into kernel. E.g. ASHs. Must ensure security when executing untrusted application code.

Visible revocation

Advantage: Library operating systems have more control.

Disadvantage: Requires interaction between kernel and library operating system.

Abort protocol

Prototype

Aegis (Exokernel)

ExOS (Library OS)

Performance

Very impressive. Compared to state-of-the-art implementations from literature, at least five times faster on operations such as exce ption dispatching and IPC.

Discussion Points

There is no clear evidence about how much each technique counts in the overall performance improvement. It seems that a large part of performance gain comes from compiling the code and downloading it into the kernel. If most performance comes from downloading code into the kernel, does it still make sense to try so hard to push kernel towards hardware? Maybe we only need a way of downloading low-level code into kernel?

Migration. To make the library OS migratable, we need to build some hardware abstraction layer above exokernel. How large should such a layer be? If it's large, then why we need an exokernel? What's its impact on performance? This problem is not addressed in this paper.

Pushing kernel towards hardware essentially increases the amount of work to be done by application developers. How much extra work need an application developer do now?

Compatibility with existing O.S. Though Exokernel is highly extensible, how compatible is it with existing OS?