[cap-talk] Object-Capability Patterns: An Historical Overview

[Jed Donnelley]

On 3/20/2008 8:55 AM, Jonathan S. Shapiro wrote:
> On Thu, 2008-03-20 at 14:46 +0100, Pierre THIERRY wrote:
>> Scribit Bill Frantz dies 19/03/2008 hora 23:00:
>>> As a side note, Charles has recently come to think that this operation
>>> is not used frequently (or at all), and is therefore not necessary.
>> Is incrementing the protected payload of a capability, in Coyotos,
>> considered severing the capability?
> 
> No. The increment you are looking for is the increment of the
> *allocation count*, which *is* a severing operation. The protected
> payload of a capability cannot be altered once the capability is
> fabricated.
> 
> A protected payload may be *logically* severed (i.e. the server will
> behave as if it is unrecognized), but it is not severed at the OS layer.
> 
>>  If yes, does the cancellation
>> forwarding protocol[1] devised during discussions about the Hurd seem a
>> useful use?
>>
>>   1. http://www.bddebian.com/~wiki/hurd/ng/cancellationforwarding/
> 
> 
> The cancellation forwarding protocol does not seem (to me) to be useful
> in any situation at all. It violates the semantics of effects of message
> delivery. A message, once delivered, has been accepted for processing.
> Subsequent severence of the channel should have no bearing on the
> treatment of that message.
> 
> More generally, cancellation is only useful when (1) the handling of
> messages is asynchronous, and (2) the queues are deep enough for the
> cancellation to "catch up". If both conditions prevail, then you have a
> fundamental design flaw that needs to be fixed. Adding a mechanism that
> relies on the preservation of a systemic design flaw does not seem like
> a terribly good idea.

I'm not sure I'm following all the terminology (cancellation forwarding)
and properly matching it back to mechanisms and terminology that I'm
familiar with, so please take what I'm about to say with a grain of
salt.

As I mentioned, the mechanism we had was for essentially reissuing
a capability to an object.  The use we had for it was as a "poor
man's" revocation mechanism.  That is, rather than creating a
revocable forwarder for the capability and doing a revocation
after the intended use (e.g. after completion of a use by a
not fully trusted or confined application that no longer needs
access to the object), we could temporarily grant direct access
to the object and then do a "newcap" (reissue the capability) after
the operation was complete.

Of course doing so would depend on not having other outstanding
capabilities to the object.

I accept that a revocable forwarder is "better" in the sense
that it's more specific to what is needed.  However, a revocable
forwarder may have the overhead costs of extra message passing
and context switching.

If the only use for such a "reissue" call is to minimize
overhead, then it seems rather non essential and I'm content
to see it missing from our list of "Object-Capability patterns":

http://wiki.erights.org/wiki/Object-Capability_patterns

I just wanted to clarify at least our past use of this pattern.

--Jed  http://www.webstart.com/jed/