NOVA: Capability selectors cause call of invalid portal
Alexander Boettcher
alexander.boettcher at ...1...
Tue Jul 31 09:39:30 CEST 2012
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Markus,
On 31.07.2012 09:30, Markus Partheymueller wrote:
> 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?
as described in parallel to your mail ;-), the global ids are
scheduled for removal. With the patch of issue247 the cap allocator
will throw a exception if it runs out of cap selectors, so that the
code will fail early and visibly. The actual problem of using less
selectors is addressed in issue268.
Cheers,
Alex.
>
> Cheers,
>
> Markus
>
> On 30 July 2012 20:16, Alexander Boettcher
> <alexander.boettcher at ...1...> wrote: 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/
iEYEARECAAYFAlAXi68ACgkQqjRK9KYzJbOfnACgihdBYGVXNHIKvf2SiV8rQ0fH
VZAAoOvEh+VW7FR0Jk77g3btJXuixEzv
=bSqI
-----END PGP SIGNATURE-----
More information about the users
mailing list