[cap-talk] Confused Deputies and Rights Amplification

[Charles Landau]

At 1:48 PM -0500 2/4/08, Jonathan S. Shapiro wrote:
>Norm will jump in if I get this wrong, but I think it is safe to say
>that both of us feel that no rights amplification operation should exist
>in a properly designed capability system.
>
>Or at least, that was his initial position, which gave both of us some
>discomfort about the can-opener operation in KeyKOS/EROS.
>
>Subsequently, I have modified my stance on this. It seems fairly clear
>that:
>
>   Any rights amplification operation that could, in principle, have
>   been accomplished in the absence of the amplification operation
>   (perhaps with a much higher storage or computational cost). Is
>   not, strictly speaking, a rights amplification operation at all,
>   and MAY be acceptable if it is implemented with sufficient care.

>I guess I would add one other qualifier. There are certain patterns,
>such as seal/unseal, that CAN be implemented without an amplify
>operation, but can only be implemented sensibly if 'eq' is available,
>and can only be implemented efficiently if something like "keybits" is
>available.  The decision to admit EQ into a design is a fairly
>fundamental decision.

That has always been my belief. Indeed, I don't know how to show that 
any rights amplification operation is safe, if it doesn't obey the 
above. And this is the reason I believe EQ is a necessary operation.

>One view of the debate is that EQ, by virtue of
>violating identity encapsulation, is itself a rights amplifying
>operation.

We said above that in a system with EQ but without other rights 
amplification primitives, you can theoretically implement rights 
amplification.

It would be interesting if it were possible to show that in a system 
with rights amplification but without EQ, you can theoretically 
implement EQ.

>Oh. The essence of the user-mode implementation of canopener is that the
>fabricator of processes with a particular brand can maintain a private
>copy of all of the capabilities that it fabricates. Cracking open an
>Endpoint for this purpose (equivalently: a red segment) is borderline,
>but can be viewed as providing only a trivial extension of the notion of
>EQ.

To clarify: In KeyKOS/EROS/CapROS, when you send a message to a red 
segment/wrapper/forwarder, the message goes to the object's 
keeper/keeper/target, which is a start cap to some process. An 
amplified (non-opaque) cap to the red segment/wrapper/forwarder is 
added to the message. (The argument that *this* amplification is 
implementable with EQ is left as an exercise to the reader.) The 
fabricator of processes could theoretically call the object to be 
amplified, then observe all the processes it fabricated and, using 
EQ, see if any of them received the (unique) reply cap to the caller. 
If so, it can retrieve the amplified cap. So the argument is, since 
this form of amplification can be implemented with only EQ using 
destructive testing, it is OK to provide a primitive operation that 
is efficient and nondestructive.

At 7:20 PM -0800 2/19/08, Norman Hardy wrote:
>Actually the can opener was O(n). It was for pure convenience and 
>nominally to bundle authority.
>As we used it each programmer would have his own can opener for the 
>things he had programmed.

I can't find "canopener" in the KeyKOS document. Are you both talking 
about the key-indexed directory? It did not do amplification, just EQ.