Object descriptors vs sender id

[Jonathan S. Shapiro]

Einar has said several important things. Here are some clarifications
and responses.


On Mon, 2003-12-22 at 17:55, Einar Karttunen wrote:
> Eros:
> - The sender just marks this information inside the descriptor.

The sender does not control this information. The information in the
descriptor is set by the *server* when the descriptor is fabricated. The
server can trust this information precisely because it is NOT fabricated
by the sender.

> - Access check is done with a simple comparison

Other patterns are also possible.

> - The state is not visible to the client 
> - ipc is a little bit slower

There is no evidence for this last statement in terms of actually
measured latency.

> L4: 
> - The state is either 
>  - visible to the client 
>   - the client can mutate it -> expensive checking
>   - the client can pass it to others without supervision

The EROS client can likewise pass capabilities without supervision,
subject only to the requirement that the sender must hold some
capability allowing it to speak to the recipient.

> Modelling L4 with Eros
> 
> - The server uses a word of data in the descriptor
> - The kernel fills it with the caller-id (needs hacking)

The LAST thing you want is to clobber this field with the caller id. My
proposal (at present) is that the kernel should provide to the server
BOTH the word in the descriptor and also the caller id.

However, I propose that the value of the caller ID should be set in
software by the thread manager. When one wants L4 behavior, one sets it
according to thread-id. When one wants caller anonymity (as in EROS),
one simply sets the field to zero for all processes.

The issue: in the EROS design, it would be an *error* to reveal the
sender ID as the L4 kernel currently does.

> Modelling Eros with L4
> 
> - This seems quite difficult to archive without additional lookups.

Agreed.

> - How can one build a *safe* mechanism on top of L4?

Today, one cannot. With thread mappings, one is closer, but the design
is ACL-centric, and ACLs are known to be unsecurable in principle.

> - All API based approaches fail because malicious clients can send
>   handcrafted messages.

*IF* you believe that checking the principal (sender) id is a viable
design approach, then the server can check for such malice.

The problem is that the server *MUST* check for such malice. That is,
any server that fails to check for malice of this kind is simply
incorrect.

Since this check at server level is mandated by the IPC API, it is
appropriate to consider it part of the cost of the IPC.

shap