Re: Why COPY != SIMULATED COPY

[Espen Skoglund]

[Jonathan S Shapiro]
> On Wed, 2005-10-19 at 20:41 +0200, Espen Skoglund wrote:

>> Just did a LITTLE thinking, and I have a question about what we
>> REALLY want here: Do we really want what I just stated?  Or in
>> other words: Does B really want to trust the hierarchy between
>> "Cap.1" and "Cap.1..x" to not perform any revocation?
>> 
>> If the answer is NO then it seems to me that what we actually want
>> is:
>> 
>>   "B has Cap.1.y"
>> 
>> Comments?

> Given a chain of cap transfers of the form


>               ANY    ANY    RevCOPY     COPY
>       ... S ---> T ---> A --------> B -----> C

> We want it to be that case that 

>   (1) C's capability gets revoked exactly when B's
>       capability gets revoked, and
>   (2) any revocation of A's capability causes the
>       capabilities held by B and C to be revoked also.

> That is, we are trying to simulate the behavior of the obvious
> kernel-implemented COPY operation. This definition of RevCOPY/COPY
> composition is required if we are to preserve any possibility of
> confinement.

> B might overwrite its capability before the revoke occurs, and this
> should not cause C's copy to disappear. That is: B and C hold
> co-equal copies after the COPY operation.

Right.  This is clear.  My question was more about what you actually
want to achieve in practice.  That is, if C wants to be paranoid about
the capability not suddenly disappearing (because of malice or fault),
it must make sure that all the subjects that can revoke the cap it
receives are subjects that it trusts.

If we have the case that C is paranoid, and if there exists a path
between A and B above and C only trusts A, then getting a co-equal
capability from B does not satisfy C's paranoia requirements.

On the other hand, if we don't have this paranoia requirement, then
just adding the few lines of code that implements COPY in L4 is no big
deal at all.

I suspect that you never really had to deal with scenarios such as
these in EROS since you generally only perform COPY operations and
thus don't have long chains of revocable copies.

        eSk