* Exokernel: An Operating System Architecture for Application-Level
* Resource Management
* Authors: D.R. Engler, M.F. Kaashoek, J. O'Toole Jr.

EXOKERNEL: thin software layer that securely multiplexes and exports
physical resources.  Exokernel explicitly avoids providing high-level
abstractions and instead exports all physical resources.  They solve
the following problems:

1) High cost of abstractions that favor the resource utilization style
of some applications over others

2) Abstractions hide information and cannot be circumvented, making it
impossible to implement specialized resource management abstractions

3) Since typical OS abstractions must be shared by all applications,
they change slowly and few advances are implemented in production
systems

Exokernel and end-to-end: applications know better than the OS what
their resource utilization will be and thus having the OS manage
resources violates end-to-end.  Is this a valid argument?

On top of the exokernel lies library operating systems that implement
the particular resource abstractions used by applications.  Most
applications will simply use a compatible library OS instead of
rolling their own.

DESIGN

Philosophy: avoid resource management and provide secure low-level
primitives that allow (as closely as possible) direct hardware access.
Principles: Expose Allocation (allow requests for physical resources
like physical pages, etc), Expose Names (export hardware names, like
physical page numbers), Expose Revocation (thus allow library OSes a
chance to pick which resources to release, e.g. page eviction).

Secure Bindings: Authorization to use a resource is checked at bind
time, i.e. when a resource is bound to an application.  Then access
checks can be implemented efficiently without performing the complex
authorization process.  To implement secure bindings, applications
need a way to express efficient access-time protection checks.  Secure
bindings are implemented using 3 methods: hardware tricks, software
caching, and downloading application code.  The paper gives examples:
multiplexing physical memory using address translation hardware and a
large software TLB and multiplexing the network using downloadable
packet filters.

Downloaded code: used to implement secure bindings, but can also be
used to improve performance.  First, downloaded code eliminates some
kernel crossings.  Second, the execution time of downloaded code can
be readily bounded, therefore they can run when the application is not
scheduled.  Thus context switching to the application which downloaded
the code is not necessary; the paper gives the example of packet
filters.  There is no need to schedule each application in turn to see
if it needs to process the packet.

Visible Resource Revocation: OSes can guide deallocation, such as page
eviction.  Some resources are best revoked invisibly, however, since
they are revoked frequently and a context switch would be expensive
for each revocation.

Implementation details of Aegis, an exokernel, and Exok, a library OS,
are in paper.