Comparing IPC and capability invocation

[Marcus Völp]

Jonathan S. Shapiro wrote:

>1. The current EROS design is currently expressed in terms of capability
>registers. We have decided that this should be replaced with a
>capability address space. Conceptually, this capability address space
>serves the same role in our architecture that the thread address space
>serves in Ln.
>
>2. The elements indexed by this address space are capabilities in EROS,
>but thread-ids in L4. This is the heart of why I think of this as the
>"threads vs. objects" distinction.
>  
>
I think the EROS capability space and the L4 address spaces are the 
same: the difference is that the address space -- or better call it name 
space -- in L4 is partitioned per type:  i.e. a name space exists for 
memory (the virtual address space), a second name space for threads is 
under discussion.

Both spaces contain capabilities, i.e. pointers to objects -- the thread 
/ page frame -- complemented by a set of rights (read, write, execute). 
The difference is the way of how those capabilities itself are handled:

EROS has the take and grant_e function (_e to distinguish with the 
mapping grant: grant_m), L4 maps and grants capabilities and is able to 
directly revoke through unmap.

...

>First, switching to descriptors should not significantly change IPC
>performance. A descriptor is probably a larger data structure than a
>thread id, but in both cases there is a load instruction at the end to
>place the target thread address into a register. This is true in both a
>thread-id design and a descriptor design. The difference would be only
>that the thread structure pointer might live at a different offset.
>
Global IDs have the benefit to directly translate to the TCB address (+- 
some masking). Local IDs bear a potential for a TLB and a Cache miss, 
thereby the smaller the descriptor the more descriptors fit into a 
cacheline and performance might be better with smaller descriptors. 
Note, this is just a guess and we have to evaluate this in particular 
for SMP systems where false sharing might effect the performance negatively.

...

>An added word about the 'object' type may be useful, since it reflects a
>significant philosophical difference between L4 and EROS.
>
>In EROS, a client invokes an object. This object may be an entire server
>(a process) or it may be a particular object that is served by that
>server. In L4, the "particular object" case is customarily handled by
>passing an object id as an argument to the IPC operation. One problem
>with this is that the object id can be forged by the client.
>  
>
The question here is whether we have to support unforgeable object IDs 
in the kernel or whether unforgeable sender IDs as we have now are 
sufficient. Given an unforgeable sender ID, the invoked object ID can be 
validated to be accessible by the sender.

How is the object invoker identified in EROS? If I understand EROS 
right, you send a resume capability with the object invocation and have 
a compare and get_type operation on the capabilities. Can you make use 
of this capability to reliably distinguish calling clients?

...

Marcus