l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

version of thread ids


From: Marcus Brinkmann
Subject: version of thread ids
Date: Tue, 20 May 2003 21:13:08 +0200
User-agent: Mutt/1.5.3i

Hi,

I used to propose that we use the version field of a thread id to identify
the PID of the task the thread belongs to.  I also suggested that these
numbers are not reused until all relevant parties acknowledged the death
notifications (well, in effect.  the exact semantic was that they could get
and release references to the PID).

This was quite good, unless I realized that the PID must be the same after
exec.

You want an exec to be a fast operation.  This means you want to reuse the
PID quickly.  For secure exec, you must make sure that all resources are
released, thus you have to make sure all interested parties notice that the
task is being replaced.  This has the consequence that the PID as defined
by POSIX is not a good version number, because it does not change, and can
thus not be used to differentiate between the object handles to the old now
dead task or the new task with the same PID.

However, using the version number to identify the task is still useful for
all the benefits I discussed previously (in particular to make IPC task
based without a lot of overhead).  Thus I think that the compromise is the
following:

The version number becomes the task ID "TID".  For example, the TID could
also be valid as an object handle to the task server.  It uniquely
identifies the task.  A task is a different concept from a process entirely,
just as it is in Mach based Hurd today.  The proc server maps pids to tasks
and vice versa as it does now.  As we already have this situation now, the
Hurd code doesn't need to be changed to support such a setup.  A server can
still securely determine the PID from a user thread by looking up the PID
from the TID using the proc server, as the TID in the thread id can not be
faked.

Now it is clear that the exec server needs to allocate a new task id for a
secure exec and kill the old tasks, as it does now.  This will invalidate
all extinct object handles to and from the task.  In the new exec protocol,
I said that for secure exec all send rights to the "task port" need to be
invalidated, but that is not enough.  So now we use a completely new task
object (in fact it is sufficient to just change the version ID and let the
task server mark the old task id as dead [incl notifications and everything],
there is no need to recreate the address space), and that will work out ok.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]