Re: Comments on the hurd-on-l4 document

[Niels Möller]

Marcus Brinkmann <address@hidden> writes:

> At 08 Jun 2005 16:30:36 +0200,
> Niels Möller wrote:
> Yes.  One solution is that the map/grant/unmap model will be extended
> to communication pairs: You can map communication points to other
> threads by sending them in a message, just like memory mappings.  The
> receive end of such a communication pair is permanently fixed at
> creation time.  Then each thread which has the communication point
> mapped can send a message.  And the receiver can choose from which
> communication end points to receive.

This sounds reasonable. That the receiver endpoint is fixed is a
limitation that must be removed in some higher layer, since at least
one has to be able to inherit a receive end point through exec.

> The receiver gets the information on which receive end point the
> message was received, but he gets _no_ information about the sender.

Well, the common case is that the server for a capability needs to
reply to whoever used the capability to send a message. I guess the
kernel has to automatically create a capability in the receivers local
name space? Perhaps even a single-use capability.

> You can separate these problems.  The first part, the capability to
> send a message, being mapped and granted, this is what the new L4
> designs contain.
> 
> The second part, the death notifications, that is the "reference
> counting" problem, and should be optional (reference counting may leak
> information and thus add covert channels).  There is a fundamental
> issue here: Microkernel designs usually despise reference counting,
> and require explicit destruction, which makes a lot of sense.  But the
> question is not if you have reference counting at the lowest level,
> but if you can add it on top of that, and this is where I have not yet
> seen a convincing solution.

Hmm. Maybe you can see the capability reference counting service as an
optional service.

A server gets to choose to kill the corresponding object when the
capability server sends it a no-senders notification, or it can keep
it open, causing no great harm to anybody else.

Clients get to choose to either register their capabilities with the
capability server, and be guaranteed that as long as the server
doesn't crash or misbehave, the capability will work. Or it can choose
to not register it, and then all that happens is that it risks that
the capability may stop working at any time. An unregistered reference
will in effect behave precisely as a "weak reference" to the server
object. I don't think there's a security problem with allowing this
choice, it might even turn out to be useful.

To make this robust, the cap server needs to cooperate with the task
server so that references are deleted on task death. And we must
ensure that a task can't register a reference to a capability that
nobody granted it (or else, a malicious task could create "fake"
references and in effect, disabled no-senders notifications for random
objects). This latter requirement might be non-trivial.

If capabilities can be unilaterally revoked by the server, this must
also be handled properly. Perhaps it's sufficient to give the server
the responsibility of informing the cap server of any revoked
capabilities.

If we compare the set of mapped/granted capabilities according to the
kernel, and the view of the capability server, we can probably not
maintain a perfect correspondence, but we can probably use some
relaxed constraints on this correspondence, and still get things to
work out.

> There are some aspects of the design
> which are obvious, but consider this call to the capability server:
> 
> cap_get_ref (cap_server, cap)
> 
> The cap server needs to identify what the object "cap" is.  If this is
> just a mapping, it can't know that.  So, again, you need to lookup
> objects associated as caps when the caps are given as arguments.

I don't think I fully understand this. If it helps, one could have the
cap server maintain a unique id to each capability, and pass this id
around in all ipc that needs it (no idea about the security concerns
though).

> Disclaimer: I may change my mind anytime :)

I'm afraid it's not useful to get too much into details until we know
which services L4 will and will not provide.

Does this mean that l4-hurd development is effectively stalled until an
updated L4 spec is published?

Regards,
/Niels