Object descriptors vs sender id
Hello I would like to make few notes on the recent discussion on Eros object descriptors vs the L4 sender id. Sorry if I have misunderstood parts of the discussion. The main problem is imho how can the sender know the client is entitled to use the service? Eros: - The sender just marks this information inside the descriptor. - Access check is done with a simple comparison - The state is not visible to the client - ipc is a little bit slower 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 - stored inside a non-related thread - instead of two ipc operations we need three (C->S->C becomes C->store-thread->S->C) - stored inside server (more complexity, granting permissions is hard) - All servers need to store client state. - Upon each request we typically need a hash lookup - Clients need to communicate passing descriptors to the server - The pager adds a prefix scheme does not really help as the server does not necessarily trust the clients pager. The following come into mind as problem cases: - A client using thread pool - A permission for all children of a thread (or capabilities in general) Also the Eros model seems to map better to a distributed enviroment. In L4 one would need to allocate one thread per remote client/thread/set of permissions while in the Eros model just hold different capabilities. Modelling L4 with Eros - The server uses a word of data in the descriptor - The kernel fills it with the caller-id (needs hacking) Modelling Eros with L4 - This seems quite difficult to archive without additional lookups. - How can one build a *safe* mechanism on top of L4? - All API based approaches fail because malicious clients can send handcrafted messages. - Einar Karttunen
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
- The pager adds a prefix scheme does not really help as the server does not necessarily trust the clients pager. A client can receive its mappings from several other processes including from the server.
Modelling Eros with L4
- This seems quite difficult to archive without additional lookups. Provided that L4 adopts Generalized Mapping, to me it increasingly seems easy to emulate EROS capabilities as a special case.
--hermann
participants (3)
-
Einar Karttunen -
haertig＠os.inf.tu-dresden.de -
Jonathan S. Shapiro