From: Ian King (iking_at_killthewabbit.org)
Date: Mon Mar 01 2004 - 17:44:45 PST
The authors describe Denali, a software layer somewhere between a virtual memory
monitor and an operating system that abstracts the resources of a physical
machine to the end of providing protection and isolation between applications,
with the target application type being Internet protocol servers. The system is
implemented on the x86 architecture, and the authors also implement a "guest OS"
to provide services on top of Denali. They provide performance benchmarks
appropriate to Internet space, in comparison with a standard BSD implementation,
which demonstrate that Denali extracts an acceptably low performance penalty for
its level of protection.
What really intrigued me here was the formalizing and extension of a lesson in
Disco: it is possible to take fidelity of virtualization too, too far. In
Denali, some of the true uglies of the x86 are hidden behind the virtualization;
while the cost is that legacy OSs will not run on Denali without modification,
that is not the goal of this effort. The authors discuss a pending project to
implement Linux on top of Denali and, given their description of the virtual
interface, it seems likely they will be successful. It is especially
significant that Denali's creators sidestep the x86 hardware TLB - historically
one of the most problematic "features" for any multitasking OS.
I again invoke the gods of UNIX and proclaim that the creators of Denali
listened to their holy words: do one thing and do it well. By virtualizing and
avoiding the temptation to provide too many services (e.g. a network protocol
stack), the authors kept Denali small and focused. It would have been
interesting to learn more about Ilwaco and the interface between it and Denali.
Another powerful feature was the virtualized, simplified internetwork for
virtual machines within Denali; this allows OS and application programmers to
use a simple, well-understood metaphor as the underpinnings of all sorts of
features, including but not limited to intermachine data sharing. Network-based
(i.e. loosely coupled) sharing is well understood, and by removing significant
overhead from this level, the authors have legitimized it as the primary sharing
mechanism for cross-VM communication.
It is also interesting to note that the virtualization of disk storage actually
improved some benchmarks, as data would often be found in physical memory. The
authors briefly touch on the semantics of sharing disk space, as well, another
simple and clean intermachine communication mechanism.
The implementation addresses the dynamics of a Zipf distribution very well,
according to the metrics offered; VMs that most commonly have work are retained
in physical memory, and the relevant mechanisms are efficient to page or swap in
those less-commonly-used VMs - an extension of how this same metaphor has been
commonly applied to processes in a swapping system.
When reviewing the performance metrics, it is crucial to keep in mind that the
goal of Denali is to allow arbitrary code to run side-by-side on a single
physical machine, with minimal risk to other running code. As the authors
state, this goal is sought with multiple processes, but the needs of
interprocess communication and infrastructure, together with the multiple layers
of abstraction present in nearly every modern operating system, compromise the
isolation. In Denali, inter-application communication is seen as an occasional
phenomenon, and providing for same is not allowed to compromise the goal of
isolation. This focus on its goals hies back to operating system work such as
Multics, in which it was designed for security first, and all other feature
planning had to work within that framework; fortunately, according to this
paper's metrics, Denali's performance did not suffer from this as much as that
of Multics. Indeed, the performance hit was often negligible, and the
isolation, not only from other applications but from the realities of the
hardware itself, made the system substantially more secure.
This archive was generated by hypermail 2.1.6 : Mon Mar 01 2004 - 17:51:37 PST