Re: emulating no-senders notifications in L4?

[Marcus Brinkmann]

On Thu, Dec 20, 2001 at 11:35:48AM +0100, Niels Möller wrote:
> Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
> > I think basically, you have described that we need a seperate port server
> > that maintains port rights.  I guess so much was already clear.
> 
> Perhaps I should state some more of my assumptions: (i) L4 provides no
> security features that can be used to directly implement the
> capability-like access control needed for Hurd rpc, and (ii) for most
> Hurd rpc, the separate message and reply rpc:s aren't essential, and
> neither is the queueing of messages (I can expand on these points, but
> I'm doing my best to be brief, this message is quite long already).

I concur.  As I wrote in my other mail, the queueing of messages is not
necessary and asynchronous messages are not common.

Although, now that I think of it, if you don't queue messages there will be
messages that get lost if you transfer receive rights from one task to
another (the window where the old server doesn't accept messages on the
port, and before the new server does accept them).  I don't know if there
are situations where this harms, but it wouldn't hurt to look up in the Hurd
the places where port rights are moved to verify such things.

> > There are other requirements, like if you insert a port right into a
> > task, the port right must have the same number if a compatible right
> > for the same port already exists (like, if you get a send right for
> > a receive right, it is the same port name number). Such requirements
> > make it necessary to include some reference counting.
> 
> This is part of the port-right management and transfer rpc:s, so as
> long as it's practical at all, it's performance is not terribly
> important. I think it might be possible to do the reference counting
> outside of the port-rights server, in the task owning the right(s);
> IIRC, there's already code in libports to do something similar.

Note that this must also be true when you receive send rights in messages. 
Well, if you can get this by some extra RPCs to the port server, this might
do it (like an RPC that compares two send rights).

> > However, this is only the beginning, and as you illustrate, message
> > forwardingis achievable (btw, the mach ipc/ stuff should also have all
> > the port name translation stuff etc you did not cover).
> 
> What is port-name translation, and what is it needed for?

Well, it's what I mentioned above, if you receive a send right in a message,
it has the name of send rights to the same port you already own.  It might
be possible to implement this outside of the port server, in the task, but
with support from the port server.

Maybe you can even get rid of this assumption.  Programs like rpctrace rely
on it to find out if they already mapped a port right or not.
 
> > Port rights are task based.
> 
> And the problem is that in L4, rpc happens between threads, right?

RPCs happens between threads in Mach as well.  Nevertheless, a port right is
valid and has the same port name in all threads.

> I think this is mostly a matter of nomenclature. One could do away
> with the ports array completely if one instead identifies a port with
> its receive right (there can be only one, right?), and gives it its
> own type. I.e.
> 
>   struct port_right
>   {
>     enum { receive, send, send_once, invalid };
>     task_t owner;
>     /* For send rights, the id of the correspondign receive right */
>     unsigned port;
>   };
> 
> When you mention that, I think that's simpler and better.

Well, I can assert that there is exactly one receive right for every port in
GNU Mach.

> > To repeat, all send rights to a port in one task have the same port name.
> > I guess you were not careful enough to distinguish between ports,
> > port-rights and port names (a mistake easy enough to make, as the
> > documentation and the source often say "port" for "port name" etc).
> 
> I confess my ignorance here. I have no idea what a "port name" is, and
> if we identify a port with its receive right, I don't see any use for
> the "port" abstraction either.

A port name is the mach_port_t number a task helds to identify a port right
in its ipc space to the kernel.  If you get a send right for a receive
right, it will have the same port name.  If you have a send right and get a
send right to the same port, it wil hae the same name.  You might implement
this in the task outside the port server, or even might get rid of this
assumption.  However, I am pointing this out because you did not cover this
at all.

Everything I said should be taken as constructive criticism (things that are
not covered by what you proposed), not as weaknesses or reasons why your
idea won't work.
 
> > > Is this service good enough? Does it provide the kind of port-right
> > > abstraction that the Hurd needs?
> > 
> > I think here the answer has to be no.
> 
> Any examples of how it fails?

Well, if you say "is this service good enough" in the sense that "is this
service plus a lot of stuff in- or outside the port server" then the answer
might be yes as well, I don't know, as I have not tried to verify if all
parts that are still missing will fit together with what you proposed.  But
you have answered some of my concerns, and the only things I can think of
show where something is missing, and not where something is that won't make
it work by all means.

> > BTW, one interesting question for L4
> > is:  How do you prevent that a task sends its own, faked messages to the
> > server, circumventing the port right server.
> 
> The receiving task should make sure that it never ever processes any
> rpc except those sent by the port-rigths server. Either by comparing
> the sender of each rpc to the id of the port-rights server,

That sounds ok.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de