Linux IO_MEM session

[Johannes Kliemann]

Hi Norman,

I have tracked down the issue to the Io_mem_dataspace_capability being
invalid.
The segfault is caused by _dataspace_size() being called on an invalid
capability in region_map_mmap.cc. I think a better behaviour would be to
check the validity and throw an Invalid_dataspace() exception (I would
create a PR for this change).

> are you sure that this is the backtrace of the faulting thread? It
> doesn't look like it. To double-check, have you had a close look at the
> instruction pointer within the faulting binary as reported by the
> kernel's dmesg output?

I have taken a look at the IP and this supports the assumption about the
invalid capability as the segfault happens in
`Capability_space::ipc_cap_data`, especially in the inlined `return
local_capability_space().ipc_cap_data(*cap.data());`

> Capability_space::Ipc_cap_data Capability_space::ipc_cap_data(Native_capability const &cap)
> {
>    70b40:       53                      push   %rbx
>    70b41:       48 8d 05 f8 ff ff ff    lea    -0x8(%rip),%rax        # 70b40 <_ZN6Genode16Capability_space12ipc_cap_dataERKNS_17Nativ
> e_capabilityE>
> _ZNK6Genode17Native_capability4dataEv():
> /media/sf_kernel/genode/repos/base/include/base/native_capability.h:78
>                 Data const *data() const { return _data; }
>    70b48:       48 8b 1f                mov    (%rdi),%rbx
>    70b4b:       49 bb 50 2f 05 00 00    movabs $0x52f50,%r11
>    70b52:       00 00 00 
> _ZN6Genode16Capability_space12ipc_cap_dataERKNS_17Native_capabilityE():
> /media/sf_kernel/genode/repos/base/src/lib/base/capability_space.cc:81
>         return local_capability_space().ipc_cap_data(*cap.data());
>    70b55:       48 ba 40 cb fa ff ff    movabs $0xfffffffffffacb40,%rdx
>    70b5c:       ff ff ff 
>    70b5f:       4c 01 d8                add    %r11,%rax
>    70b62:       48 01 d0                add    %rdx,%rax
>    70b65:       ff d0                   callq  *%rax
>    70b67:       48 8b 53 08             mov    0x8(%rbx),%rdx
>    70b6b:       8b 43 10                mov    0x10(%rbx),%eax
> /media/sf_kernel/genode/repos/base/src/lib/base/capability_space.cc:82
> }
>    70b6e:       5b                      pop    %rbx
>    70b6f:       c3                      retq

70b67 is the instruction that fails. I don't know if this helps you in
any way.

> As another question, did you first try to hand out an FD for a regular
> file as I suggested in my last email? Just to rule out potential
> problems with the FD obtained from your kernel module.

This happens no matter which file I have opened.

> The 'rm.attach' - when executed on Linux - is just a process-local
> operation. It comes down to an invocation of 'mmap' in
> 'region_map_mmap.cc'. Maybe it helps to instrument the code there? For
> instrumentation at such a low level, I recommend using the 'raw'
> function instead of 'log'. The 'raw' function directs the output
> directly to the kernel - not to core's LOG service. You won't see the
> component's name as log-message prefix, but rule out any interaction
> with core by the instrumentation.

I looked into other implementations of base-linux that use the
Dataspace_capability. They all just instanciate and return it. This is
also the case for the Io_mem_dataspace_capability yet it seems to be
invalid by default.
I tried to return a Dataspace_capability but it can't be casted.
As far as I understand it I have to either validate the
Io_mem_dataspace_capability or cast to it.

Regards,
Johannes