l4io_request_iomem() destroyes ioStream

Björn Döbel doebel at os.inf.tu-dresden.de
Mon Jan 5 12:59:13 CET 2015

Hash: SHA1

On 05.01.2015 12:38, ba_f wrote:
> Hello L4-Hackers,
> i noticed some wiered behavior when using l4io_request_iomem().
> Have a look at this simplified code:
>> Server::dispatch(l4_umword_t, L4::Ipc::Iostream &ios){
>> ios >> v1; ios >> v2;
>> l4io_request_iomem(ADDR, 4, L4IO_MEM_NONCACHED, &baseaddr);
>> ios >> v3; ios >> v4;
>> }
> When using l4io_request_iomem(), it kind of destroys the ioStream
> so that v3 and v4 get wrong values. v1 and v2 are correct and of
> course, i checked that v3 and v4 are correct when
> l4io_request_iomem() is not there.
> It's ok for me, since i just rearrange my code.
> But how does this behavior come? is it a bug, maybe?

This is intentional behavior and caused by the way clients and servers

L4 IPC basically works by the sender putting data into its UTCB and
then invoking a system call. The kernel then copies the data from the
sender's UTCB into the receiver's UTCB and wakes up the receiver if

When your server's dispatch() method is called, the arguments for the
call are still within the server's UTCB area. The Iostream's stream
operators allow you to retrieve these arguments and deal with them.

In your code you now do an l4io request, which in turn sends an IPC
message to the IO server. As explained above, for that purpose your
server will now put data into its UTCB and issue an IPC system call.
This overwrites any data that was previously stored in the UTCB and
hence invalidates the Iostream's content.

Possible solutions:
* Move the l4io request to the point where you have read all data
  from the server request, i.e., after the "ios >> v4" line.
* Alternatively, copy the whole UTCB content to an intermediate
  location before issuing another IPC.

Version: GnuPG v1


More information about the l4-hackers mailing list