From: Reid Wilkes (reidw_at_microsoft.com)
Date: Sat Feb 28 2004 - 22:03:18 PST
First an aside - I read this paper soon after finishing the Disco paper
and found this one quite refreshing. In my opinion it flows much better
and the structure of the paper is very much more cleanly organized.
That said, Denali introduces a technology and as a bonus a new category
in which to define the technology: an isolation kernel. The basic idea
behind an isolation kernel is to multiplex hardware to different
software systems in a highly secure and scalable fashion. The scenario
proposed for this type of system is that of an internet server. It is
suggested that a data center could allow many different and unrelated
internet applications to be run on the same physical hardware by virtue
of each application being run in it own virtual machine on the isolation
kernel. The isolation kernel is different from traditional virtual
machines in a couple of respects. First, the isolation kernel does not
attempt to provide a virtual representation of the hardware that still
looks to the guest exactly like the underlying hardware. Rather, Denali
provides something similar to an X86 machine language and highly
simplified interfaces to network, disk, keyboard, and console devices.
This prevents guest operating systems from being run in a Denali VM
unmodified. Second, the isolation kernel is focused primarily on
providing scale rather than providing an environment capable of running
a complete modern operating system. By providing a simplified,
abstracted representation of the underlying hardware to guest VM's,
Denali can begin to achieve this scale.
The simplified X86 instruction set that Denali exports to VM's provides
two large benefits. First, the isolation kernel can run the instructions
unmodified on the actual hardware. Second, Denali does not have to do
some of the tricks that more traditional virtual machine monitors must
perform concerning protected instructions executed by the guest code.
One very surprising aspect of the design was the lack of a virtual MMU.
This means that all the code executing inside a VM is in a single
address space. At first this seemed very limiting but as I read more of
the paper I began to realize that this is very much in keeping with the
design goals of Denali. The key for me to understanding Denali is that
it is not trying to provide an environment in which to run anything like
what we generally call an "OS". In fact, Disco can be described as a
thin layer on which operating systems run whereas in many ways Denali IS
the operating system. So Denali is very much a departure from the
concepts of virtual machine monitors as in Disco. In fact, I would be
more tempted to describe Denali as a cross between the idea of a kernel
- based implementation of a .NET or Java runtime and the Exokernel
system. Like Exokernel, all code in a Denali VM is essentially user code
and the huge majority of OS abstractions are left to be built in the
application space. Like a user-mode programming language runtime, Denali
has its own input language and provides a simplified abstraction of
certain services (although at a much lower level than the abstractions
provided by .NET or Java runtimes). In addition, Denali, like .NET,
provides a great deal of separation between the various programs running
on the system. It is important to note, however, that the authors of the
paper claim greater security for Denali than is possible with a system
like .NET because layer below attacks are less possible in an isolation
kernel.
This archive was generated by hypermail 2.1.6 : Sat Feb 28 2004 - 22:03:21 PST