Rights Amplification

[Marcus Brinkmann]

At Thu, 16 Jun 2005 09:19:12 +0200,
Alexander Warg <alexander.warg at os.inf.tu-dresden.de> wrote:
> 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.

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

Yes, but that is easy enough.  As Espen said, as an extension, you
could allow to provide a small number (Espen said "2-4") of
translation IDs that are checked.
 
> I'm not rerally sure, I would like to have ownership seperated from
> object creation and have a mechanism to transfer or share ownership.

In Espens model, one extension is to have one type of mapping of ID
objects (via access bits, I presume) that maps the ability to read out
the protected payload.

The difference in the two models is not the notion of "ownership".  In
L4.sec, "ownership" is defined by having the receive right.  In
Espen's ID object model, ownership would be defined by two things: The
actual owner of the ID object, used for comparison, and the right to
read out the payload.

The difference of the two models is that in Espen's model you read
out a payload, that is the kernel stores a user-settable word in
association with the ID object, while in L4.sec's model with cmp(),
you have to know the object to identify before you can do the
comparison.  This is the main difference, and it has consequences.
One is that the comparison can only happen after the information about
which objects the capability is for was transfered.  So either you
would have to split up a request into two IPCs, one to transfer the
object identifiers, and one to transfer the actual capabilities, or
you would have to transfer both and let the server do the cmp()
post-IPC (which is the only feasible way to do it, IMO, as having a
single request split up in two IPCs is just an open door for denial of
service attacks in a server-client model).

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

For your model, the aliasing issue exists, but you could still allow
the user to store a payload with a communication point that is
subsequently read out.

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

It's true that in Espen's model the number of potential owners of an
object at translation time is limited to either 1 or a small number.
That's a limitation of some sort, it's true, but not one that concerns
me a lot (or at all, that is).

Thanks,
Marcus