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
-----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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
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@...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@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-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
some more comments.
On 30.07.2012 19:19, Markus Partheymueller wrote:
for RPC reach numbers >= 0x100000, RPC calls fail because of calls to
the kernel does only support cap selectors up to 1 << 24 (which is 0x1000000), however selectors only up to 1 << 20 (which is 0x100000) as base can be mapped/delegated. (There are only 20 bit available for the base of the capability range descripter, see also the NOVA kernel specification, section - 4.3.4 Object Capability Range Descriptor).
Effectively that means that every cap created at indexes above 1 << 20 can't be delegated. For me it looks like that you create (and close) timer sessions often enough that you may run into the problem you described. (As described by issue 247 no caps are ever freed or reused, which is the actually the root problem.)
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?
In Genode@...127... indeed global ids are used, however they are not called at all. The global ids are only used to lookup objects inside services.
To be more specific: In the Genode in the base/include/base/native_capability.h there exists the Dst and local_name member. Dst is used in base-nova actual as portal selector, whereas local_name is used to held the global id.
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
This looks strange, at least the creation of portals at indexes above 0x100000 should be no problem. I created caps above 0x100000 here in a test case at Genode@...127... and I don't see this behavior. For creation of portals you should be able to specify up to indexes up to 1 << 24.
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?
The global ids are scheduled for removal from Genode soon.
In issue 268 [0] they are already gone. Additionally unused cap selectors are actually really freed if used together with the solution from issue 247.
For me your described problem didn't occur anymore when using [0] and [1].
Cheers,
Alex.
[0] https://github.com/genodelabs/genode/issues/268 [1] https://github.com/genodelabs/genode/issues/247
-----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@...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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Sorry,
I forgot to mention that the described limits of course apply only to the 32bit version of the kernel interface. For 64bit the limits are different.
Alex.
On 31.07.2012 09:33, Alexander Boettcher wrote:
the kernel does only support cap selectors up to 1 << 24 (which is 0x1000000), however selectors only up to 1 << 20 (which is 0x100000) as base can be mapped/delegated. (There are only 20 bit available for the base of the capability range descripter, see also the NOVA kernel specification, section - 4.3.4 Object Capability Range Descriptor).
-
Alexander Boettcher -
Markus Partheymueller