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@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.