[cap-talk] Midori in The Register

Toby Murray toby.murray at comlab.ox.ac.uk
Wed Jul 30 18:17:37 CDT 2008

On Wed, 2008-07-30 at 16:57 -0400, Jonathan S. Shapiro wrote:
> On Wed, 2008-07-30 at 21:29 +0100, Toby Murray wrote:
> > The work by the various L4 groups at running whole Linux stacks on top
> > of various flavours of the L4 microkernel (including some of the newer
> > capability-based ones) demonstrates that the embedded space is not the
> > only possible application area, but merely the easiest one to target.
> In this case I think not. One of the major points of Singularity was to
> do away with the address space abstraction. While I would certainly not
> put it past MS to make an architectural compromise of the sort that you
> are describing, it would be difficult to do this for Singularity/Midori.

Ah, that detail about singularity hadn't stuck. I totally take your
point here.

> Perhaps more importantly, users will not accept a "multiple worlds"
> view. Solving the multiple worlds perception would be a significant
> challenge.

Not necessarily. Plash and the OLPC system demonstrate that one can
virtualise standard POSIX APIs on top of a capability-like least
privilege system to enable ordinary applications to run with a minimum
of "other world" feel. The same technique could apply here, e.g. your
legacy apps run in a VM for which OpenFileDialog() invokes a powerbox
running in another domain on the microkernel and where fd =
open(pathname) in the VM is translated to an invocation of whatever
capability "pathname" maps to in a map maintained by the VM
etc. just like Plash does.

One could run an entire new VM per app, thereby totally removing the
"other world" feel whilst ensuring legacy applications still run under
POLA. This is, of course, exactly what Plash does.

Plash just happens to virtualise the POSIX APIs on top of a capability
system implemented on top of POSIX, rather than a capability-based
microkernel. OLPC does likewise but this time virtualises POSIX on top
of the DocumentStore interfaces etc.

More information about the cap-talk mailing list