[cap-talk] Confused Deputies and Rights Amplification
clandau at macslab.com
Tue Feb 19 23:14:56 EST 2008
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
> 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
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
We said above that in a system with EQ but without other rights
amplification primitives, you can theoretically implement rights
It would be interesting if it were possible to show that in a system
with rights amplification but without EQ, you can theoretically
>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
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.
More information about the cap-talk