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