Re: new exec server protocol

[Niels Möller]

Marcus Brinkmann <address@hidden> writes:

> I had a look at the exec server protocol, and it has two main issues:

Do I understand this correctly if the only reason exec is needed at
all for normal, non-setuid, execs, is to get the task through the
singularity where the task has no mappings?

Then I think a reasonable way to divide the work is to

1. Have a library function (libexec, libbfd, wherever) that takes a
   file port as argument and returns a new file port to the
   interpreter file, as well as any modifications to the argument
   list.

   Note that the most common case will be the interpreter ld.so. I'm
   not sure how the double-interpreter case works, where a #! script
   is interpreted by /bin/interpreter, which in turn is "interpreted"
   by ld.so.

2. An exec server implementing a single exec rpc, that takes a file
   port and an argument block as argument (the task of the caller need
   not be an explicit argument, right?). The memory block is a
   integral number of pages mapped into the server's address space
   using the L4 ipc primitive.

   Next, it maps (or loads, if the filesystem doesn't do mmap) an
   image from the supplied file port (this seems to involved rpc to an
   untrusted fileserver. Is there any way around that, except by
   getting rid of exec, as described below?).

   It also maps the given argument block into the new address space.

   It sets up a stack, copies some more information there, and starts
   a new thread.

3. The startup code of the new image looks into the argument area,
   does what ever needs doing with old ports, etc, and then goes on
   eventually calling main.

Next, let's see if we can get rid of exec completely:

Keep an exec/startup stub mapped into both the old and the new address
space, and put the exec code there (it could be mapped at a fixed
address in all processes, or it could be the responsibility of the
task that wants to perform an exec). The task will do step (1) as
before, and then call the exec stub in it's own address space. The
stub kills all other threads, unmaps everything but the argument area
and the stub itself, and then do everything the exec server would have
done. Then the exec server isn't needed at all, for ordinary execs.

As for setuid exec, I don't know. I'm inclined to say that it should
be the responsibility of the filesystem. Some hand waving: There could
be a filesystem ipc for execing a setuid/setgid file. It could do it
in three steps: (a) Like exec, kill the old threads and mappings.
Install a setuid-specific stub code into the address space, and start
a thread to execute it. (b) The stub code coordinates uid transfer
with the file server. (c) When it has changed persona, the stub
performs a plain ordinary exec.

This all makes sense to me, because setuid exec is a private affair
between between a process and a file server. The process wanting the
exec has to surrender all control, by handing over a task port (or
equivalent) to the file server. The file server needs no L4 privileges,
it only needs to be able to give away its own uid's to (cooperating)
processes of its own choice, something which *every* process should be
able to do.

Dunno if it makes sense to anybody else ;-)

Summary: exec is about managing your own address space. There's no
reason for any privileged server. And if some other process (a file
system) is willing to share some of its power, then you should be able
to arrange that by a protocol with no third parties.

Regards,
/Niels