Rights Amplification

[Marcus Brinkmann]

At Wed, 15 Jun 2005 14:44:07 +0200,
Espen Skoglund wrote:
> Since I'm linf of involved with these sort of questions myself it
> seems like the right thing for me to share my thoughts on the subject.

Thanks for jumping in here, it's very helpful.
 
> I agree that having an operation that can identify one's own virtual
> address of a mapping can be pretty neat.  Many people on this list
> have however pointed out the nasty aspects of it.  The killer
> nastiness here (IMO) is that you may potentially need to traverse the
> mapping tree all the way up to the root.  This means that no matter
> how clever a locking scheme you use for the mapping database, you may
> always need to somehow lock the root nodes in the tree.

I realize that the operation I suggested is not actually one that is
particularly desirable from its implementation properties.  I used the
map_lookup operation to describe very precisely the narrow semantics I
need in implementing the type of systems I want to implement.

I am very happy to hear that you have already considered such an
operation.  The performance effects you enumerate sound convincing.

> Another problem with cmp() is that as far as I understand it doesn't
> do what Marcus asks for.  That is, it does not identify a particular
> vaddr within the address space.

This is true, but I should add that I am not really asking for the
vaddr, but for the bigger picture of identifying objects.  I hope I
made this sufficiently clear (in retrospect, I could have made it
clearer).

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

Thank you for the detailed description of how ID spaces are designed.
I knew you had something like this in mind, but what I was missing was
the detail that you can map the ID object, but also the right to use
it for translation purposed.  With this missing piece in the puzzle, I
am convinced that ID spaces can work for me.

> I realize that these IDs do not directly solve the problems you are
> posing.  That is, it doesn't allow you to verify that, e.g., a memory
> mapping you receive really is what you expect it to be.  You can do
> certain tricks here though.  For example, a server can create an ID
> associated with every memory mapping it hands out (i.e., it maps the
> ID together with the page frame).  Someone down in the mapping
> hierarchy can then use this ID to prove to the server that it has a
> capability to the page frame.  This would for example solve the
> reference counting problem you posed.

Yes, indeed.  I would actually do it the following way: The reference
counter would become the global object server.  It would create all
the ID objects for all objects in the system, on behalf of the servers
providing the objects.  It would map the right to do the translation
to the server providing the object.  The server can then identify the
objects in incoming RPCs without any additional RPCs to the global
object server.  The reference counter can naturally identify all
capabilities, as it is the principal provider of the corresponding ID
objects.

This would work very well.  It would have slightly different
properties than a purely local model, but no differences that matter
to us.

It would require to separate communication channels from objects, but
this actually is a benefit, because more optimizations are possible.

I think that such ID objects would be, all things considered, a much
better solution than any type of map_lookup() or cmp() function.  It
does, however, require a new type of kernel objects.  What do the
Dresden people think about new kernel objects like this?

Thanks,
Marcus