Object descriptors vs sender id

Einar Karttunen 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
  handcrafted messages. 
- Einar Karttunen

More information about the l4-hackers mailing list