Re: Just a few questions

[Jonathan S. Shapiro]

On Sat, 2005-10-22 at 23:56 +0100, Justin Emmanuel wrote:
> 2) How many capabilities can a capability have? E.G. A mouse pointer
> capability loaded from a somewhere or other that also ( malevolently)
> has the capability programed in to write to the hard drive?? Whats to
> stop that happening?

I do not know how to answer the first part of your question, because it
is unclear. I *think* the answer is:

  Every capability lets some set of operations be done on *one* object.
  A process can have as many capabilities (or as few) as it needs.
  Capabilities do not hold capabilities.

The answer to the second part is: capabilities are kernel data
structures in both L4.sec and EROS/Coyotos. They cannot be forged by
applications. So either you *have* a capability to the hard drive or you
do not. You cannot "invent" one.

> Is the user requested to give permission every time
> a particular I/O operation takes place? What if you have connected a
> file system ( maybe a floppy, CD ROM) and wish to copy some directories,
> will it ask for permission on every object?

No. By connecting the directories, the user has already given the
authority. No further questions are asked.

The general rule in a capability system is:

  Authority grows from connectivity.

The bad news is that users need to learn to be careful about what things
they connect. The good news is that it is relatively easy to build user
interfaces that help users make good decisions about this, and a lot of
active and promising research about how, specifically, to do so is now
going on.

> 3) Will L4 on Hurd be using a constructor capability?

I do not know. Unless L4.sec chooses to provide a COPY operation, the
guarantees of the constructor seem impossible to achieve.

> 4) Does L4 have the answers to some of the questions raised by a project
> like Eros?

I am not sure if you mean "EROS has identified some challenges, has
L4.sec answered them?" or "EROS has some problems, does L4.sec improve
on them?"

In my opinion, L4.sec does answer many of the challenging problems that
EROS identified. Not all of them, but many of them. This is not
surprising -- many of the key ideas that differentiate L4.sec from L4
were adapted from EROS. I think that the reverse is also true. Several
of the architectural changes in Coyotos come from adapting ideas in L4.

I think when we discuss problems, we need to distinguish between issues
of implementation (which can be fixed) and issues of architecture.
Fixing an architecture problem creates compatibility issues.

There are definitely some architectural warts in EROS. Some are
corrected in Coyotos. I have looked at these warts for a very long time,
and in every case I have reached the conclusion that the warts cannot,
in principle, be eliminated. In each case I can see designs that would
reduce some particular wart, but only with the cost that a different
wart comes up someplace else in the architecture. My conclusion at this
point is that the requirements for secure and robust designs cannot all
be satisfied perfectly at the same time; you can only choose which warts
are acceptable for your needs. I expect that the warts in L4.sec will be
very different from the warts in Coyotos, but there *will* be warts.

shap