Re: Why COPY != SIMULATED COPY

[Espen Skoglund]

[Jonathan S Shapiro]
> Now consider what happens in the Marcus/Neal protocol (as described):

>     STEP                         EFFECT ON SYSTEM STATE
>     [Initially]                  A has Cap

>       RevCOPY(Cap)
>    A --------------> B           B has Cap.1

>       SimCOPY(Cap.1)
>    B --------------> C           C has Cap

> At the end, A has the initial capability Cap, B has a revocable
> capability Cap.1, but what does C have? In the Marcus/Neal protocol,
> C has Cap, not Cap.1.

As far as I understood the protocol proposed, the last step you
describe is wrong.  During SimCopy() the following will happen:

        RevCOPY(Cap)
     A --------------> C           C has Cap.2

> Later, when A revokes Cap.1, C will not lose its copy. Thus
> SIMULATED COPY does not accurately simulate COPY. More importantly,
> the entire purpose of selective revocation has been defeated and a
> critical security mechanism has disappeared.

The question now is how revokation works.  Using the current L4 UNMAP
semantics, "Revoke(Cap)" actually means something like
"Revoke(Cap.*)".  That is, all revokable copies derived from Cap are
revoked (including Cap.2).  You thus don't defeat selective
revocation.

There has been other discussions about "selective revocation" in
UNMAP; not to be confused with "selective revocation" as discussed
above.  The selective revocation I'm talking about here (let's call it
"targeted revocation" to avoid confusion) allows you to specify
something like "Revoke(Cap.S)", where S is a subset of all natural
numbers (implemented as a number range, or mask, or whatever you
like).  The other important change with targeted revocation is that
someone performing a RevCOPY can decide on the child number of the new
cap.  The last step above could then be something like:

       RevCOPY(Cap, 1)
    A --------------> C           C has Cap.1 (and so does B)

Note the second argument to RevCOPY().  A can now perform
"Revoke(Cap.1)", and the copy from both B and C will disappear.

Anyhow, this "targeted revocation" is a bit of a digression.  It is
not important for the discussion at hand.  I only mention it in case
someone has heard about the alternative UNMAP operation and wonders
how it fits in.

[...]

> Given such a CapServer, the initial part of the protocol remains
> similar:

>     STEP                         EFFECT ON SYSTEM STATE
>     [Initially]                  CapServer has Cap.1
>                                  A has Cap.1..x.1

>       RevCopy(Cap.1..x.1)
>    A --------------> CapServer   CapServer has Cap.1..x.1.1

>      [Intention: A is saying: I authorize CapServer to create
>       capabilities that are co-equal to mine]

>    CapServer ------> A           [none: CapServer is returning]

>       RevCopy(Cap.1..x.1)
>    A --------------> B           B has Cap.1..x.1.2

>       RevCopy(Cap.1..x.1.2)
>    B --------------> CapServer   CapServer has Cap.1...1.2.1

>       ??MagicOp??(Cap.1...x)
>    CapServer ------> B           [B has Cap.1..x.2]

Since CapServer knows that Cap.1..x.1.1 is identical to Cap.1, it can
perform the following last step:

        RevCopy(Cap.1)
     CapServer ------> B           B has Cap.1.y

> This gives the correct outcome, because A cannot now revoke B's
> copy, but revocation of any capability *upstream* from A causes the
> capability held by B to be revoked.

> The remaining questions are:

>   1. By what authority is CapServer permitted to fabricate a
>      capability cap.x....y (for arbitrary y) given that it already
>      holds a capability cap.x? That is: what is "MagicOp"

CapServer need not have the authority to fabricate a new capability.
It simply needs to identify "its own version" of the the capability
and RevCopy this version to B.

>   2. How do we make sure we get the permissions right? That is: what
>      are the proper arguments to MagicOp?

CapServer must have the right to inspect the permissions of the
capability it receives from A (i.e., Cap.1..x.1.1).  It can use these
permissions as a mask during the RevCopy operation.  (In L4 speak: it
can use these permissions in the MapItem for the UNMAP operation.)

        eSk