Re: Why COPY != SIMULATED COPY

[Marcus Brinkmann]

Hi,

the clarity you bring into the discussion is delighting.  So is the
depth of analysis.

I did realize before that making a simulated copy from a revocable
copy does defeat the revocation mechanism.  In my recollection we even
talked about this in Dijon, very briefly.  I think you pointed out
this defect, and I argued the following way how you can "repair" the
ability to revoke:

We can have a special bit in the capability, that works in the same
way as access bits (rwx) (ie, can be cleared by the sender, but not
set), which has the following semantics: If the bit is set, then
revocation can be defeated by performing a simulated copy.  If the bit
is cleared, then the cap server will deny a request to make a
simulated copy: The revocability property wins.

At the time you pointed out that one should reconsider a design that
requires adding more and more bits and features to make it work right,
and that was of course spot on.

Now you add another argument: That simulated copies only works at the
"lowest level": As soon as a revocable copy is made that doesn't allow
simulated copies, you can not make simulated copies of _that_
capability.  And this is perfectly true.

Is this a critical failure?  If you are a purist, definitely.  In
practice, I am not so sure.  So far, in our design, we only wanted to
use simulated copies or revocable copies.  I have not encountered a
situation where I would want to make a simulated copy of an
explicitely[1] revocable copy ([1]for lack of a better terminology).
All this means is of course that either our hierarchies are, in fact,
extremely flat, or we have just not foreseen all our requirements yet.

Of course, this is just a playful way of saying the following: The
_only_ system you can reasonably implement with such a cap server is
one with a flat capability hierarchy.  And in such type of systems, I
guess, you really want the copy operation to be the primitive
operation, and not revocable copy.  And the other way round: In a
system with deep hierarchies, simulated copy is not adequate enough.
So, in either type of systems, you need the copy operation as a
primitive operation (and I think you also need revocable copy, but we
already knew that).

So, yes, I think you hit the nail on the head and drove it home.  

What follows is just some further elaborations on the subject.

Here is what you _could_ do, but let me point out that I am not saying
that we should do it.  The capability server could support a new
object type, a "wrapper object" that does "transparent" forwarding.
Originally, I was going to say that B should implement such a wrapper
object, but of course it can't, as then it could not exit without
destroying all copies derived from the wrapper object!  The wrapper
object would "swallow" the revocable copy from A and provide
normal-looking capabilities from which simulated copies can be made.

Hey, I have just reinvented EROS wrapper objects in the cap server,
except that because this is a user space extension of the IPC system,
it sucks!  At the very least it requires additional IPCs for the
forwarding.  Also, it can not be made transparent given current L4
designs.

At this point it seems useful to point out that EROS wrapper objects
can't be nested either, or only in a limited fashion.  However, there
is an important difference: In the EROS case it is a kernel
implementation detail, while in the presently discussed case it is
mainly a kernel interface and feature issue.  And of course the
performance and security implications (DoS attacks) of both solutions
are _vastly_ different.

Thanks,
Marcus