Re: Revocation vs destruction

[Jonathan S. Shapiro]

On Fri, 2005-10-14 at 16:12 +0200, Marcus Brinkmann wrote:

> One issue that keeps confusing me is the distinction between object
> destruction and revocable copies of capabilities.  You stress that
> explicit object destruction is important.  You say that revocable
> copies is sometimes a desirable feature, but in general it's not
> common at least in EROS.

They have different use cases. Object destruction is when you want the
object gone. Permanently.

Revocable copies is when you want to be able to *selectively* revoke
access to the object. For example, you would like to revoke *my* access
but not lose your access.

> OTOH, if revocable copies are pure forwarding objects, and the
> instantiator of a revocable copy can not intercept the messages, then
> verification of implementation could equally done for the revocable
> copy.

In this situation, you can trust the implementation of the object, but
you cannot trust the durability of your *access* to the object. These
are two distinct issues, and this is part of why wrappers need to be
detectable. Also, in EROS creator of a wrapper is in a position to alter
what it points to, so you can only "identify" successfully through a
wrapper in special circumstances. This is *not* the case in the L4/L4sec
MAP operation.

>   The receiver only needs to know if the object is a revocable
> copy or not to determine if it needs to deal with object destruction.

I see that this is confusing. Here is the metric:

  Object destruction can be performed by:
    1. Anyone holding a capability that permits an object-implemented
       destroy operation (in which case the object will destroy
       itself).
    2. Anyone who can destroy the source of storage (including
       it's super-banks, since the banks are a hierarchy).

  Selective revocation can be done by anyone who inserts
  a wrapper.

It often proves to be true that if you know the identity of the object
this is sufficient to know something about the circumstances under which
it might be destroyed. Similarly robust statements of safe reliance do
not seem to be possible for wrappers in any common case we have seen.

I am ignoring the special case in which the wrapper was created by the
object server in order to exploit the larger protected payload field
that can be achieved by using a wrapper. In EROS this functionality is
*also* provided by the wrapper, and I should be clear that this is NOT
relevant to the discussion of REVOCABLE COPY.

> But I am not happy with this characterization, at it is purely
> phenomenal, and doesn't really connect with the actual use cases and
> design patterns at a global scale.  My question is thus, what is the
> real functional difference between the two?  I think one of my
> problems is that I am pretty familiar with the design patterns with
> map/grant/unmap, having spent some time thinking about them.  But I am
> not familiar with design patterns employing explicit destruction, and
> trusting the implementation of objects.  Maybe there are some typical
> examples which show where explicit destruction (or the inability to
> destroy a copy!) is a big plus over revocable copies?

Your question about use cases is a good one. I only got about 4 hours
sleep last night, and I am not in a state to answer this coherently at
the moment. I definitely need to give some use cases.

However, do my comments about destruction vs. revocation above help any?


shap