Rights Amplification

[Alexander Warg]

On Wed, 2005-06-15 at 14:44 +0200, Espen Skoglund wrote:
> Now, just for the sake of confusing people even more, let me throw in
> another idea I've been playing around with.  My take on the problem of
> application specific capability transfer is to introduce another type
> of address space; an ID space.  One can fabricate new IDs within one's
> ID space and also map/grant/unmap such IDs between ID spaces.
> 
> The fabricate operation would take two parameters:
> 
>    Fabricate_Id (id, number) --- where id is the location within one's
>      ID space and number is a number associated with that ID.
> 
> When the user does an IPC it can specify to send an ID as some form of
> protected payload to the destination.  On the destination side, the
> receiver specifies an ID to use for translation purposes.  During the
> transfer of the ID the kernel checks if the two IDs reside within the
> same owner space.  If so, the actual transferred value is the number
> specified when creating the ID.  If not, an "invalid" value is
> transferred.
> 
> Translation of an ID takes constant time.  It simply involves checking
> whether the owner space of two IDs are the same.  An extension of the
> translation process is to allow a small number (say 2--4) IDs be
> specified as translation IDs.  Another extension is to have an access
> right that allows the ID to be used for translation purposes.  Without
> this right the ID can only be used as a protected payload.

This sounds fairly the same like the proposed cmp() operation, the only
difference is that you do it in combination with IPC, wich is only a
performance argument, and however may be the right way.

The similarity is as follows:
The compare operation takes two capabilites (only communication
capabilites are valid). The first one is well known by the one that does
the compare and must have a compare right (similar to your translation
right). The second capability is the one which is unknown. If the
compare right is given and the two capabilites point to the same object
(in our case this would be an end point) the 'badge' which is a
protected number assigned to this capability is returned by the compare
and is therefore similar to your protected name. If either the compare
right is not given or the capabilities are not communication caps or the
point to different objects the compare will return the invalid badge.

I think, if we have a way for cheap temporary mappings of capabilities
the compare is more flexible, however if we havn't we should consider
doing the compare during IPC by giving a local capability to compare to
in the receive and getting the compare result in the message.

-- 
Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20050615/bb43acae/attachment-0001.asc>