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

What kind of paper is this?

• Idea paper: create the right abstractions to expose hardware
• AKA: The purpose of the OS is simply to allow for secure multiplexing of hardware; library operating systems implement system interfaces and policies.
• With implementation and evaluation of idea.

The Story

• Once upon a time, operating systems encapsulated interfaces between hardware and software, a set of abstractions, implementations of those abstractions, and policies for managing abstractions and resources. Some application developers found this arrangement suboptimal: the policies and abstractions provided were not precisely what the application wanted or needed. Along came the Exokernel architecure, which securely exposes hardware resources, allowing applications to manage these resources using their own abstractions and policies. This made everthing run faster, and everyone lived happily ever after.

The Case

• Allowing a single OS to define and implement abstractions suffers from three problems:
  1. Precludes domain-specific optimizations
  2. Discourages changes to existing abstractions (and their implementations)
  3. Restricts application developer flexibility
• The approach
  1. Secure bindings: bind to resources to handle events
  2. Source revocation: applications know how to give back resources
  3. Abort protocol: allows breaking of secure bindings (to punish misbehaving applications).

Random Thoughts

• Applications that know what policies they need are fine, but when you have different collections of applications, how do you arbitrate among them? "because library operating systems need not multiplex a resource among competing applications with widely different demand." But who arbitrates among the competing library operating systems? If you run those on different machines, then how is this different from just running a custom OS on each machine?
• This feels a bit like VELOSITY.
• Extending or specializing a library operating system might be considerably simplified by modular design. It is possible that object oriented programming methods, overloading, and inheritance can provide useful operating system service implementations that can be easily specialized and extended, as in the VM++ libra

Exo Design

• Three key functions
  1. Track ownership of resources
  2. Guard all resources or binding points
  3. Revoke access to resources
• "However, as in all systems, an exokernel must include policy to arbitrate between competing library operating systems: it must determine the absolute importance of different applications, their share of resources, etc. This situation is no different than in traditional kernels"
• Secure bindings
• Three techniques to implement secure bindings
  1. Hardware: e.g., TLB, frame buffer tags
  2. Software caching: Software TLB, capabilities
  3. Downloading application code: packet filters
  • TLB entry: binding is putting something in the TLB; then used multiple times

Implementation

• Aegis: Exokernel (MIPS)
• ExOS: Library OS
• Glaze: SPARC-based Exokernel
• PhOS: Parallel OS (for Glaze)
• What do we want eval to show?
  • Demonstration of what you can do on Exo that you cannot do on other systems?
  • Performance is only interesting (IMHO) in that it allows you to do something efficiently that is impractical on other systems.
  • Comparisons with fully functional commercial operating systems is significantly less interesting, because you're comparing a special-purpose system to a general one.
  • Sigh: not what they show us!
• Interesting: In some cases the effects amounted to a factor of three performance penalty. Changing the order in which ExOS’s object files are linked was sufficient to remove most conflicts (could one rearrange the Makefile of the Ultrix kernel as well?).
• Aegis
  • CPU: a vector of timeslices. Allocate big, long running jobs as a set of contiguous chunks; allocate interactive jobs in periodic locations.
  • Processor environment: sounds like a big union in which you define all the difference things that can be delivered as events to an application.
  • Performance numbers remind me of Leidtke
• Virtual Memory
  • Application VAS split in two segments
  • Exokernel manages "guaranteed mappings" in one segment
  • Faults in the other segment or in unguaranteed mappings are forwarded to the library OS/application
  • So both Aegis and the library OS have to maintain page table like structures?
  • Application still has to invoke protected call to Exokernel to install mapping.
• Protected Control Transfer
  • Substrate for implementing IPC
  • Sounds a lot like Leidtke -- in fact, they compare
  • But it's unclear the comparison is fair as you have to put stuff on top to get actual IPC and the platforms are different, requiring different amounts of work at the time of the transfer.
  • Two different forms of transfer: synch and async
• Dynamic Packet Filters
  • Compiles code upon filter installation
  • Uses VCODE generator

ExOS

• Because Aegis has a light substrate upon which to build IPC, ExOS can implementa variety of IPC mechanisms, while doing so on Ultrix is expensive.
• The VM system is pretty primitive (no real page table; just a linear array of mappings); no swapping
• Fast network packet handling through ASH (Application specific handlers) -- download code into Aegis - maintain safety through sandboxing and code inspection.
• Demonstrations of extensibility
  • Inverted page tables (better for sparse address spaces)
  • tlrpc: Server saves callee-saved registers (or skips saving them if it doesn't use them)
  • Stride scheduler: implements a proportional share scheduler

Feature Analysis

1. Features that are common practice
   • Library OS: I wouldn't call them common practice, but there does seem to be a resurgence of interest. We'll come back to this discussion as we look at modern library OSs.
2. Features that are not used and should stay that way
   • This isn't exactly the right category: but how big a problm is it that the Exo kernel still has to do resource allocation among the different library OSs?
3. Features that are not used but should be reconsidered
4. Features for which the jury is out
   • The separation of key features into protected kernel subsystems and application pieces (e.g., IPC, VM)
   • I guess I'm still torn on whether the Exo interface is "the right one" for constructing systems.