Object descriptors vs sender id
ekarttun at cs.helsinki.fi
Mon Dec 22 23:55:27 CET 2003
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?
- 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
- 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
- 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
- Einar Karttunen
More information about the l4-hackers