CSE 221 Paper Evaluation

Greg Johnson (johnson@SDSC.EDU)
Mon, 5 Jun 2000 22:11:58 -0700 (PDT)

If I've counted correctly, this is an "extra" evaluation, but writing it
helped me solidify thoughts on the active networks link.


D. Engler, M. Kaashoek, and J. O'Toole, 1985.

Just when you thought you had a good handle on "good" design principles
(abstract away details of the hardware from applications for example), a
paper comes along that throws a wrench in the works. This is such a one.
The overriding exokernel design principle is to enable good performance
and flexibility by implementing resource access primitives at a very low
level (as close to the physical hardware as possible). Thus protection
(associated with the physical hardware itself) is separated from manage-
ment policies (a higher level concept). In fact, the exokernel design
moves several elements of the traditional OS, such as virtual memory,
and IPC from the kernel to the application level. The exokernel itself
does little more than: provide secure access to resources, track owner-
ship of resources, and revocation of access (handled through the use of
secure bindings, visible revocation, and an abort protocol).

The second half of the paper looks at the performance of an exokernel
implementation (Aegis) in tandem with a library providing higher level
OS-type functions (ExOS), compared with that of a UNIX variant (Ultrix).
In all cases Aegis / ExOS outperforms Ultrix, often by significant margins,
while providing application level control over hardware resources in ways
not previously possible. Many of the improvements in performance arise
from the lack of complexity in Aegis and ExOS, the use of code downloading,
and dynamic code generation (the generation of executable code on the fly).

Based on these results, the authors show that: exokernel simplicity =
efficiency, fast exokernel primitives = fast access to hardware resources,
higher level functions can be efficiently built on top of these primitives,
and higher level abstractions may be extended or modified as needed by the
application domain.


It seems like the exokernel model might have some application in the area
of active networks, specifically in the areas of resource allocation and
protection. Here, network nodes must contend with arbitrary code from
untrusted sources, yet provide resources for these programs efficiently.
Several active network implementations focus on limiting the execution
environment, and / or providing costly security checks or decryption.
Alternatively, an exokernel could be placed in charge of node resources
(the small size of the exokernel is a bonus), along with a library of
higher level functions which might be called by active packets. In some
sense the source of the packet is no longer relevant. In the worst case,
computations invoked by packets can only kill themselves.

Greg Johnson office: (858) 534-8367
Senior Programmer Analyst fax: (858) 534-5152
San Diego Supercomputer Center email: johnson@sdsc.edu
University of California San Diego