Object descriptors vs sender id

[Einar Karttunen]

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