Rights Amplification

[Espen Skoglund]

[Marcus Brinkmann]
>> 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?)

> It would make sense to me if it is the address space of the thread
> (or the thread itself) that created the ID object in the first
> place.  I don't think that ownership can be transfered.  I think it
> works similar to receive rights, which are, in Espen's model, bound
> to a thread, and can not be moved or copied, either.  It's fixed at
> creation time.

Just to clarify; my choice of words when I said "owner space" could
probably have been better.  What I really meant was "origin space" or
"space in which the root mapping for the ID resides" (let's call it
"root space").  If you use the latter definition it should be clear
that one can transfer "ownership" by granting the root ID to another
space.  This gives a bit more flexibility to the model, has some minor
implementation issues, but nothing that one can't deal with.

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

> Although map_lookup is not longer in the picture, let me say that it
> didn't have the aliasing problem, because the ancestor would be
> unique.

Right.  Aliasing where the application can use two names to identify
the same physical resource: good.  Aliasing where the kernel has to
choose the name to idenity a physical resource with: bad.

The model I've proposed---both regarding ID spaces and receive
endpoints being fixed to specific threads---was chosen specifically
because it avoids aliasing problems.  This means that there are both
no semantic ambiguities and that one can implement the model really
efficiently.

	eSk