headers
Espen Skoglund | 2 May 2003 15:33
Picon
Favicon

ANNOUNCE: L4Ka::Pistachio version 0.1

The L4Ka team is happy to announce the first release of the
L4Ka::Pistachio microkernel.

L4Ka::Pistachio is the latest L4 microkernel developed by the System
Architecture Group at the University of Karlsruhe, Germany, in
collaboration with the DISY group at the University of New South
Wales, Australia.  It is the first available kernel implementation of
the L4 Version 4 kernel API (currently code-named Version X.2), which
is fully 32 and 64 bit clean and provides multiprocessor support.  A
broad overview of L4Ka::Pistachio and the L4 Version 4 API can be
found in:

   http://l4ka.org/projects/pistachio/pistachio-whitepaper.pdf

L4Ka::Pistachio is built from ground up incorporating the research
results of the last seven years of microkernel and multi-server
research.  The code is written in C++ with a strong focus on
performance and portability.  The first release includes support for
many of today's widely used commodity architectures:

   o Intel IA32 (Pentium and higher)
   o Intel IA64 (Itanium1)
   o PowerPC 32bit (IBM 750)
   o Alpha (21164)
   o MIPS 64bit (R4000, R5000)

The variety of supported architectures makes L4Ka::Pistachio an ideal
research and development platform for a wide variety of systems.
Additional architectural support for AMD64, ARM, Power4, and
UltraSparc is either planned or already in progress.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marcus Brinkmann | 4 May 2003 17:56
Picon
Favicon

task death notifications

Hi,

I was thinking about task death notifications, and noticed how hard it is to
get them right on L4.  I don't remember a thorough discussion of them, I
think Neal and me just took it for granted that it was straightforward.

But it isn't.

First, why are they needed?  If a client sends an RPC to a server, there are
two possible cases: The RPC can be processed quickly, then the server just
does and tries to send the reply.  If that succeeds, fine, otherwise it will
just drop the request.  The other case is that the RPC blocks for a long
time.  This is the case for, for example, io_select.  Now, an io_select call
can last forever, for example selecting on a pipe that is never written to.
The pipe can last forever, too, for example if it is a named pipe.

Now, what happens if the client dies before the io_Select call completed? 
Then the server needs to notice, and free the resources associated with the
select call.  Associating the resources with the pipe is not appropriate,
because the owner of the pipe might be different from the owner of the
client.

So, the server needs to request notifications from the task server for the
client's thread id.  And if that thread is destroyed, the server can receive
the notification and cancel the pending request.  This only needs to happen
for blocking RPCs.  Other RPCs are by definition too short to worry about
this.

Now, the straightforward implementation: Receive RPC, read sender thread id,
send death notification request to task server for this thread id, process
(Continue reading)

Permalink | Reply | 4 comments |
headers
Wolfgang Jaehrling | 4 May 2003 21:46
Picon
Picon

Re: task death notifications

On Sun, May 04, 2003 at 05:56:03PM +0200, Marcus Brinkmann wrote:
> Either we would need an L4 extension that adds timestamping to
> (some) messages, or, we could use another, earlier time, for
> comparison, the time we start to receive messages.

Why not let the client pass the timestamp to the server?

Cheers,
GNU/Wolfgang
Permalink | Reply | 1 comment |
headers
Marcus Brinkmann | 4 May 2003 22:22
Picon
Favicon

Re: task death notifications

On Sun, May 04, 2003 at 09:46:56PM +0200, Wolfgang Jaehrling wrote:
> On Sun, May 04, 2003 at 05:56:03PM +0200, Marcus Brinkmann wrote:
> > Either we would need an L4 extension that adds timestamping to
> > (some) messages, or, we could use another, earlier time, for
> > comparison, the time we start to receive messages.
> 
> Why not let the client pass the timestamp to the server?

We don't trust clients.  The client could guess the future time that is
necessary to pass the check.

Thanks,
Marcus

--

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus <at> gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann <at> ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/
Permalink | Reply | 0 comments |
headers
Niels Möller | 4 May 2003 23:38
Picon
Picon
Picon
Favicon

Re: task death notifications

Marcus Brinkmann <Marcus.Brinkmann <at> ruhr-uni-bochum.de> writes:

> I was thinking about task death notifications, and noticed how hard it is to
> get them right on L4.  I don't remember a thorough discussion of them, I
> think Neal and me just took it for granted that it was straightforward.

The way I've been looking at this, each server will have to manage
all "port rights" for all "ports" the server receives messages on.
There will be a table that lists each thread (or task) that is allowed
to send messages to the port.

The primary operations that modifies this table, I think, are

  (i) when the server creates a new port right, and returns it as the
      result of an rpc. For instance, dir_lookup on a directory may
      return a port right to a file in that directory

  (ii) when the server, on the request of some client, transfers (or
       copies) a port right to a different task. The protocol for
       doing this have been discussed earlier (although I'm not sure
       if the perfect solution was found).

Now you are talking about a third operation,

  (iii) deleting a port right, and all associated resources, because
        the thread that held the port right has died.

I think the natural way to get the (iii)-type updates right, is to
request a thread death notification whenever a new port right is
*created* as the result of an operation of type (i) and (ii).
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marcus Brinkmann | 5 May 2003 00:02
Picon
Favicon

Re: task death notifications

On Sun, May 04, 2003 at 11:38:38PM +0200, Niels Möller wrote:
> I think the natural way to get the (iii)-type updates right, is to
> request a thread death notification whenever a new port right is
> *created* as the result of an operation of type (i) and (ii).

Yow, that's right!  I completely forgot about that.  At some point I will
have to write this all down, so I don't keep forgetting things ;)

This changes everything.

> On Mach, we have "port death notifications" and "no senders
> notifications". When servers manage their own port rights, it seems
> these can be unified, the server needs to get "sender death
> notifications" in some way or the other. When such a notification is
> received, the sender count for the corresponding port can be
> decremented, and when it reaches zero, a "no senders" event can
> be generated internally in the server.

It's not really tied to the Mach notifications, I think.  We still can use
port death and no senders notifications, but they are just callbacks in the
server called by the library implementing ports at the server side.
Task death notifications will indeed be used to decrement send rights.  And
they will also have to be used to cancel pending requests from that task.
In Mach, this can be implemented entirely within the ports system.  On L4, I
think it will be a bit different, for performance and also because we have
to avoid a DoS attack in the current Hurd where you can use any port as a
reply port (and the server can not track who owns it).  I can justify this
because reply ports are usually special anyway (they get special treatment
in glibc, they are usually send once rights, and so on).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marcus Brinkmann | 5 May 2003 19:00
Picon
Favicon

reuse of task IDs

Hi,

now, I stumbled upon a couple of serious issue.  They are all similar to the
task death notification issue.  The basic problem is synchronizing IPC with
task creation and death.

All proposals so far have put a object system with server side managed
objects, and client handles that specify the server (thread id) and the
object (object id).  Clients send messages directly to servers.  (Remember
that in L4, all messages are routed through the ports system in the kernel. 
Sending and receiving messages is unrelated, as well as ports and tasks).

Note that one consequence is that in Mach, it is easy to move a port
(receive right) from one task to another, while in L4, moving an object from
one server to another is downright impossible in this simplistic scheme.
Ludovic noticed this when considering persistency.  This is just a note, as
moving objects is not a requirement for the Hurd.

However, Ludovic persistency remark has an analogous counterpart: It is
impossible to notice if a server was replaced by another task!  Imagine you
run vipw to edit the password table.  Then you go and make yourself a
coffee.  While doing that, the /etc filesystem is restarted (for example, it
died because of a bug, or because it is networked and the connection was
lost, whatever).  Now, an attacker tries to hijack the server's thread and
task id, and succeeds in that.  You come back and save your file by sending
io_write to the thread id you still have in memory, and the data ends up in
the attackers hand.

Now, you might say that task death notifications solve this, but there is
still a race between receiving the notification and sending the io_write.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Peter 'p2' De Schrijver | 5 May 2003 19:49
Picon
Favicon

Re: reuse of task IDs

Marcus,

Wouldn't it be much easier if L4 supported the session concept ? I mean L4
actually knows when a thread dies and it could invalidate all sessions with
this thread...

Thanks,

p2.
Permalink | Reply | 3 comments |
headers
Marcus Brinkmann | 5 May 2003 20:32
Picon
Favicon

Re: reuse of task IDs

On Mon, May 05, 2003 at 07:49:43PM +0200, Peter 'p2' De Schrijver wrote:
> Marcus,
> 
> Wouldn't it be much easier if L4 supported the session concept ? I mean L4
> actually knows when a thread dies and it could invalidate all sessions with
> this thread...

What is a session?

If you mean that L4 should support some form of ports, well, then I'd think
that the L4 designer will respectfully disagree :)  Their IPC is truly
minimal, but that is the reason it is so fast.  If you look at my proposal,
you will see that in the most often used RPCs (simple message with no object
handles), we can preserve this maximum performance without loss.

Thanks,
Marcus

--

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus <at> gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann <at> ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/
Permalink | Reply | 2 comments |
headers
Marcus Brinkmann | 5 May 2003 20:36
Picon
Favicon

object management and IPC a bit more formal

Hi,

here what I proposed in a bit more formal way.  Hopefully this helps.

Thanks,
Marcus

Tasks and Threads
=================

The version part of the thread ID is used as the PID.

The thread ID part is split into a subsystem ID and a thread ID.

Any task can request a reference and task death notification to any
other (existing) PID.  This prevents the PID from being reused until
the reference is released (for example in response to a task
death notification).

Object Management and IPC
=========================

A server S provides objects.  Objects are identified to clients by the
server that provides them and a server-wide unique object ID.  Clients
are identified to the server by their thread ID (and thus by their
PID).  L4 guarantees that the sender's thread ID in the message is
correct.

Over the whole time, S keeps a reference for A's PID in the task
server to ensure that it is always the same client task sending the
(Continue reading)

Permalink | Reply | 8 comments |

Gmane