NOVA: Capability selectors cause call of invalid portal

[Markus Partheymueller]

Hi Alex,

thank you for your help. I just realized that I was already looking at
the right place, I guess: The Capability range descriptor (Crd) shifts
the unique ID 12 bits to the left, which means there are only 20 bits
remaining, which would be 0xfffff. Your solution in branch issue247
works for me, as far as I can tell for the moment. Not creating too
many portals/capability IDs is certainly a desirable goal. But I still
think is not very robust if bad things happen just because the global
IDs hit 0x100000. Maybe it could be possible to detect this overflow
and fail gracefully?

Cheers,

Markus

On 30 July 2012 20:16, Alexander Boettcher
<alexander.boettcher at ...1...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> this is a known issue described in [0]. The available fix [1] is
> currently not in genode master nor staging. If you want you can give
> it a try.
>
> Cheers,
>
> Alex.
>
> [0] https://github.com/genodelabs/genode/issues/247
> [1] https://github.com/alex-ab/genode/tree/issue247
>
> On 30.07.2012 19:19, Markus Partheymueller wrote:
>> Hi,
>>
>> I am quite stuck with a problem I encountered when using a timer
>> connection in Vancouver. As soon as the unique IDs of the
>> capabilities for RPC reach numbers >= 0x100000, RPC calls fail
>> because of calls to invalid portal numbers. In my particular case,
>> there are 4 portals created:
>>
>> [ 0] EC:0xc0019f00 SYS_CREATE PT:0x1a06 EC:0xa7 EIP:0x139950 [ 0]
>> EC:0xc0019f00 SYS_CREATE PT:0x1a07 EC:0xa7 EIP:0x1398d0 [ 0]
>> EC:0xc0019f00 SYS_CREATE PT:0x1a08 EC:0xa7 EIP:0x139950 [ 0]
>> EC:0xc0019f00 SYS_CREATE PT:0x1a09 EC:0xa7 EIP:0x1398d0
>>
>> In base/include/base/rpc_client.h, I inserted a debug statement
>> showing that the "internal" portal being called is 0x82260. I think
>> this is due to the translation between global capability selectors
>> and NOVA portals, is that correct?
>>
>> When the internal IDs hit 0x100000, what happens is this:
>>
>> [ 0] EC:0xc0019f00 SYS_CREATE PT:0x30e6 EC:0xa7 EIP:0x139950 [ 0]
>> EC:0xc0019f00 SYS_CREATE PT:0x30e7 EC:0xa7 EIP:0x1398d0 [ 0]
>> EC:0xc0019f00 SYS_CREATE PT:0x30e8 EC:0xa7 EIP:0x139950 [ 0]
>> EC:0xc0019f00 SYS_CREATE PT:0x30e9 EC:0xa7 EIP:0x1398d0
>>
>> But the next event in NOVA is a call to portal number 0x100018,
>> which doesn't exist because it was not created beforehand. It
>> seems to me that from this point in time, the internal IDs are
>> being used as NOVA portals somehow. But all I found was this
>> unmarshalling method in base-nova/include/base/ipc.h:
>>
>> inline void
>> Genode::Ipc_istream::_unmarshal_capability(Genode::Native_capability
>>
>>
>>
> &cap)
>> { long unique_id = 0; _read_from_buf(unique_id); int pt_sel =
>> unique_id != ~0L ? _rcv_msg->rcv_pt_sel() : 0;
>>
>> cap = Native_capability(pt_sel, unique_id); }
>>
>> I put another debug instruction there and found out that
>> rcv_pt_base was 0x100018, when the call failed.
>>
>> Right now I'm quite lost in all that RPC and Capability wrangling.
>>  Maybe someone can shed some light on this? How is that translation
>>  between internal IDs and NOVA portals done, anyway?
>>
>> Cheers
>>
>> Markus
>>
>> ------------------------------------------------------------------------------
>>
>>
>>
> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond.
>> Discussions will include endpoint security, mobile security and
>> the latest in malware threats.
>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________ Genode-main
>> mailing list Genode-main at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/genode-main
>>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAlAWz5QACgkQqjRK9KYzJbPfrwCfS5w5knUdyq7j8mW2C+wyDq8S
> M08AoMBGF26af9biQxSbfaiEX9cAC1Bp
> =48Qx
> -----END PGP SIGNATURE-----