Amoeba's approach to capabilities

[Ludovic Courtès]

Hi Bas,

Bas Wijnen <address@hidden> writes:

> I think anything protected by sparsity is fundamentally flawed and
> unacceptable, especially for something as critical as the kernel.

I think I understand what you mean.  The problem is that I don't
understand how it relates to Amoeba's capability implementation,
summarized like this:

     A capability typically consists of four fields as illustrated in Fig. 2.
  1. The put-port of the server that manages the object
  2. An object number meaningful only to the server managing the object
  3. A rights field, containing a 1 bit for each permitted operation
  4. A random number, for protecting each object

(1) is a globally-unique identifier returned by the kernel, (2) is
computed by the server managing the object, and (4) is computed using a
secret random number known only to the server (the random number itself
is not part of the capability, unlike one might think from the above
description).

How _this_ is protected by sparsity?  Perhaps this is just a matter of
vocabulary.  However, my understanding of this is that capabilities are
computed using information known only to the server implementing them,
which makes it "hard" to forge new capabilities.

Maybe the whole difference is here: I consider that "hard" means "next
to impossible" (if you know that a given server implements an object on
a given port, you still have to guess 80 bits, which is not something
that can reasonably be performed by brute force), but you seem to
believe that it's not that hard.  Is that correct?

Thanks,
Ludovic.