Within this framework, the only directly supported operations on such capabilities are map, grant, unmap and IPC. The map operation can be used to delegate the capability, grant can be used to move the capability and unmap to revoke it. The IPC operation allows clients to send messages to an object, for example, to invoke operations on the object.
I think here is a difference to our view on capabilities: The IPC operation allows to send a message through an endpoint to a server. The server could somehow identify the sender of a message.
The question here is really if the L4 IPC "capabilities", ie communication end points, can be used to implement "capabilities" of a capability system. The answer of course differs, depending on which requirements you choose for the capability system. We are looking here specifically at a requirement for a certain form of rights amplification, or synergy in general.
Oh, now I understand what you want to do: Implementing a "real capability" system on top of L4 with the ability to amplify rights.
You seem to say that this should not even be attempted.
I beliefed that you can build a system without kernel support for rights amplification.
I think that there is an excellent chance that the upcoming security features can be used to build a fast and secure object/capability system. Solving the problem of multiple object references in messages is essential for that. However, I am even more sure that without any kernel support, implementing a competitive and secure capability system on top of L4 is nigh impossible.
Ok, you need kernel support for that. The remaining open question is: What is the right operation for that?
The map_lookup() has the disadvantage that it is time bound by the depth of the mapping tree. And it only works within the mapping hierarchy. This is a problem for example with external object caches or different proxies which try to map_lookup() siblings of the mapping tree.
So why not use a more general and faster operation like cmp()?
bool cmp(Address first, Address second)
Are there any arguments against this stronger operation?
Thanks,
Bernhard