ports suggestion

[Richard Wesley Todd]

First let me say I'm new to Mach, L4, and the Hurd, so if this is
way off please forgive my ignorance.  The list seems dead and I
hope this at least starts up the conversation again.

It seems like the biggest problem going to L4 is that Mach's
fundamental communication channel is a port, and L4 has no
such thing.  Here's an idea that I _think_ gives us most things 
we really need from a 'port.'

First, the generic scenario (suggestion follows):
1) Thread 21 from task 3 sends an IPC to some server 'A'. 
   L4 fills in the source id itself, so there can be no
   forgery.
2) Server 'A' calls a library routine to authenticate the
   connection.
3) This routine finds the effective UID and GID of the
   caller, and returns it to A. (more on this later)
4) Server 'A' decides whether or not to fail the request.

Obviously, the hard part is (3).  Here is my suggestion:
We have a library (think of it as libports if you like) that
that:
  - Keeps an internal hash table of task/thread id's, their
    UIDs, and the timestamp when it got the information.

  - When asked to authenticate a connection, it checks the
    hash table.  If it finds the caller, it asks L4 when that
    thread was created.  A timestamp older than our information
    means it's still good.  This takes care of id wrapping. 

  - If the cached info is too old, or we don't have the 
    caller's information in the table, it sends IPC to 
    proc asking for the UID info (we must be able to 
    trust proc--is that a problem?).
  
Does this make sense?  Let me fill out my earlier example:

3a) Server 'A' calls the libports routine to authenticate this
    IPC.  
3b) The routine cannot find the id in it's hash table, so it
    sends an IPC to proc to get the info.  This is stored in
    the hash table, along with the current time.
3c) Server 'A' decides this is an ok connection, and handles the
    request.

Later, if the same thread sends another message....
3a) Server 'A' calls the libports routine to authenticate.
3b) The routine finds the UID in the hash table, and queries
    L4 for the timestamp of the caller's task/thread.  The
    thread has been up since before our saved timestamp, so
    we don't need an IPC to proc.  We just return the
    hashed authentication.

This strikes me as an efficient, secure way of doing port-like
message handling.  What do you think?  I'm sure there are holes
in it but I thought I'd jump in and contribute to the list.

As for querying L4 for the timestamp, it unfortunately doesn't
fall under lthread_ex_regs, since that only gives info for
threads in the current task.  In the name of efficiency, I'd
suggest either extending lthread_ex_regs, or adding an eighth 
system call.  (I know that won't be popular, but we are trying
to facilitate the most fundamental act the Hurd performs...and
the alternative is more IPC messages.) 

Sincerely,

Richard Todd
address@hidden