Rights Amplification

[Alexander Warg]

On Thu, 2005-06-16 at 01:48 +0200, Marcus Brinkmann wrote:
> At Wed, 15 Jun 2005 17:48:29 +0200,
> Alexander Warg <alexander.warg at os.inf.tu-dresden.de> wrote:
> > 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.
> 
> It's not quite the same because then you would have to know in advance
> which capability the user will likely provide.  In Espen's model, the
> two capabilities only need to have the same owner to make the
> translation happen.

I'm not sure how this works, what is the definition of owning a
capability. I think there is no such definition and because of that you
need as far as I undersood in espens model provide a capability with the
translation right that has the same owner space (whatever the difinition
of this is, and how can one transfer ownership?) --- so you need to
provide a capability for the translation which you know in advance has
the same owner space as the one likely to be sent to you.

In our model we have no definition of an owner of a capability (in my
terms every one that has a capability for an object owns that
capability). So we decided to have to specify one specific capability
(as in Espens model) which only needs to point to the same object as the
one send in the message. 

If you have some idea how to describe ownership of an object other than
having a capability with a specfic right like in our case the compare
right please let us know.

> I am not sure what type of optimizations would be possible within the
> L4.sec model.  It seems to be a difficult problem.  Because L4.sec has
> multiple possible receivers, it doesn't have a single owner to
> validate a translation efficiently (that's why you don't really want a
> lookup, but "just" a comparison).  But from the point of view of a
> user, Espen's ID objects, at least in isolation, seem to be all-around
> easier to use and likely more efficient (in fact, close to optimum,
> really).

I'm not rerally sure, I would like to have ownership seperated from
object creation and have a mechanism to transfer or share ownership.
Because not having this limits the systams which may be build extremely
and things such as transparent proxies are very dificult to implement.

We want no lookup because it is not only inefficent but also may return
an unintended result. Because there may be more than one capability
pointing to the same object in one address space (aliasing). The result
of a lookup may return a capability to the object which the server
itself may not have a interpretation for, because some library could
have mapped an alias that the server does not know of.

The separate compare has the following advantage you can comapre with
multiple local capabilities even if they point to different objects
served by different owners, however a model of trust may exist for a
bunch of capabilities that point to objects at a different server.

-- 
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/20050616/241bb660/attachment-0001.asc>