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