Dynamic creation and passing of IPC channels

[Björn Döbel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Robert,

[..]
>>> Capabilities are passed around through standard IPC. The 
>>> difference is that you don't put them into the UTCB's message 
>>> registers but instead you out a send flexpage into the UTCB
>>> buffer registers. Note, that the receiver must be willing to
>>> receive and therefore has to add a receive flexpage on its side
>>> beforehand.
>>> 
>>>>> Can anyone point me to some helpful documentation or maybe
>>>>> an example I could cannibalize to implement this
>>>>> (preferably in C, but C++ code would surely be helpful
>>>>> too)?
>>> 
>>> Unfortunately, there's no example that does exactly what you
>>> want. But you might want to look at the following two:
>>> 
>>> * l4/pkg/examples/libs/l4re/streammap demonstrates delegation
>>> of resources (memory pages in this case) from a server to a
>>> client. Sending cap fpages is similar - you basically replace 
>>> Rcv_fpage::mem() with Rcv_fpage::obj() etc.
>>> 
>>> * l4/pkg/examples/libs/l4re/c++/clntsrv_ns is an adaptation of 
>>> l4/pkg/examples/clntsrv that passes capabilities the other way 
>>> round. The client creates an IPC gate, sends it to the server 
>>> through an L4Re namespace, and the server then obtains this 
>>> channel and binds a server-side thread to receive messages
>>> through this channel.
> 
> I *sort of* got this working, however there is a problem which I
> don't understand.

Would you mind sharing your example code? This would make it easier to
understand what's going on.

> [..] I also noticed that the label returned by ipc_wait() is not
> exactly the same as the value that was bound to the IPC gate. It
> seems that a 1 was added or ORed to the value. Is this indended
> behaviour?

Yes, it is. The lower two bits of the receive label contain the rights
with which the respective capability was mapped into the sender's
capability space.

As an example, this is used by memory managers to determine if a page
fault shall be served read-only or writable. If you have the
respective dataspace capability mapped with RW rights and call
Dataspace::map(), the dataspace server sees this and gives you a
writable memory mapping. If you have the Dataspace cap mapped RO, this
call will result in a read-only memory mapping.

The whole capability-rights concept is unfortunately not well
documented. :( Luckily, most of the time you won't need this feature
at all. In this case the rule of thumb is to simply use labels that
have the lower 2 bits set to 0 and mask those bits after receiving a
message, which should give you the original label.

Bjoern
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlKpej8ACgkQP5ijxgQLUNm0HwCfVKmvajYShvvVwcDYQM36YcJ1
tAUAni4UmqCUuAt4PtLQTjBhkqUOfmhV
=mJLk
-----END PGP SIGNATURE-----