Re: new exec server protocol

[Niels Möller]

Marcus Brinkmann <address@hidden> writes:

> On Wed, May 21, 2003 at 10:04:55AM +0200, Niels Möller wrote:

> > But if we do that, does it matter exactly
> > when the old pid is transferred to the new task? It may be simpler to
> > do it early, like

> You want to do such things as late as possible, when you have established
> that the exec won't fail (or it is too late to recover).  I am not sure
> if that's the point above.  In particular, if we hang in waiting for the
> startup message, it would be nice to make this interruptible, so ^C can
> recover from a hanging exec.

Good point. One needs to be careful to ensure that both tasks agree on
whether the exec failed or not, so that exactly one of the tasks
survive.

> > | Send startup          Receive startup (transfers object handles,
> > |   message               message        including <proc, 4711>,
> 
> This would be more like
> 
>                                       Send startup message
>   | Reply startup message
>                                       Receive reply

This *is* a quite complex exchange, involving the task server and
other tasks, as it transfers a lot of object handles.

> > Actually this proc registration is a little fuzzy to me. [...]

> A pid port itself only says you have control over the process it doesn't
> mean you are the process.  However, I have not yet studied the proc server
> in great detail, and there are certainly some crooks because of POSIX
> requirements etc.

I guess the proc registration should at least say which thread is the
process' signal thread, i.e. the thread that proc should send
signal-related rpc:s to.

> One important new issue (which forced me into some requirements for the
> protocol) is that of holding a reference to task IDs.  For example, a
> created task must automatically get a reference to the task ID of the task
> that created it, so that it will know for sure that the startup message
> will reach its intended target.  (How to get that thread ID of the creator
> is another issue, I don't know where to put it - on the stack?  Maybe the
> task server should provide a bootstrap handle - a simple uninterpretet word).

But it makes a lot of sense to at least have the task create rpc (to
the task server) return a reference to the task. It seems reasonable
to also install a referense to the old task into the new one, although
that seems a little harier. I know too little about task startup in
L4. The thread id can be put somewhere in the initial page granted to
the now task, I guess, but it also needs some bookkeeping in the task
server.

I think this problem should be solved as a part of the task create
protocol.

> For the suid case, this is problematic, as the filesystem server can not
> give the old task the task handle, but it also can not communicate a
> reference to the old task without race or complicated upcalls (I pondered
> several options and they all sucked).

Who will be talking to who, in the suid case?

1. Old task calls file_exec on the file server.

2. File server calls task_create in the task server, and sets up the
   initial page and thread (as the file server is going to give uid:s
   away to this task, it better have full control over it's creation).
   The user has to trust the file server, just as with any other exec.

   Note that the new task gets the file server's accounting id.

3. New task and file server performs a startup-message exchange (which
   may use different conventions than the ordinary exec, it includes
   selected auth handles from the fileserver, but no pid)

4. New task returns a startup-handle to the file server (or the handle
   the fileserver has could be reused).

5. File server passes the handle on back to the old task (and this is
   the end of the file_exec rpc).

6. The returned handle is used to perform a second startup exchange
   between the old and the new task. This includes the PID of the old
   task.

7. The new task registers with proc, and uses the auth handles from
   step 3 to change it's persona. With the proc registration, proc
   also changes the accounting id for the new task to its pid.

This seems to cover all related handles. The actual loading of the new
code to execute is omitted, hopefully it can be done in the same way
for ordinary and suid exec, with and without interpreters. For
non-secure exec, the new task gets a file handle from the old task,
for secure exec (including executable and non-readable case), the new
task must get it from the file system.

Regards,
/Niels