Hello,
The long journey of developing components for L4Re continues - a story for another time, perhaps - and I have been testing code that works with the old Subversion-based L4Re distribution on the newer Git-based L4Re distribution.
One thing that seems to be different between the old and the new is when a call like the following is performed:
l4re_rm_attach(addr, size, L4RE_RM_SEARCH_ADDR, ds, offset, L4_PAGESHIFT);
Apart from L4RE_RM_SEARCH_ADDR seemingly being replaced by a differently-named constant, L4RE_RM_F_SEARCH_ADDR, it appears that such a value for the flags is insufficient and that additional rights flags might be required.
If I omit such rights flags, I get the L4_ENOENT error value, but this worked before. So, I think I may have misunderstood the behaviour of the function. Or are there now additional constraints imposed by the region manager that prevent any inappropriate accesses from bothering the dataspace? (My dataspace does test the flags on map requests against the rights supported by the dataspace itself.)
Another difference that I see between the old and the new is in the flags used for map requests sent to dataspaces. In the old distribution, there were these definitions (in pkg/l4re-core/l4re_c/include/dataspace.h):
L4RE_DS_MAP_FLAG_RO = 0, L4RE_DS_MAP_FLAG_RW = 1,
It appears that map requests now use the following:
L4RE_DS_F_R = L4_FPAGE_RO, L4RE_DS_F_W = L4_FPAGE_W, L4RE_DS_F_X = L4_FPAGE_X, L4RE_DS_F_RW = L4_FPAGE_RW, L4RE_DS_F_RX = L4_FPAGE_RX, L4RE_DS_F_RWX = L4_FPAGE_RWX,
I think the actual values involved here are different, but I imagine that since everything should be manipulating values derived from these definitions (as opposed to maintaining separate definitions of the flags), no incompatibility would normally be observed. But the apparent lack of conservatism surprised me slightly.
Anyway, if anyone has any insight into why the attach operation behaviour is different, I would very much appreciate it!
Paul
Hi Paul!
On 8/27/21 1:45 AM, Paul Boddie wrote:
Hello,
The long journey of developing components for L4Re continues - a story for another time, perhaps - and I have been testing code that works with the old Subversion-based L4Re distribution on the newer Git-based L4Re distribution.
One thing that seems to be different between the old and the new is when a call like the following is performed:
l4re_rm_attach(addr, size, L4RE_RM_SEARCH_ADDR, ds, offset, L4_PAGESHIFT);
Apart from L4RE_RM_SEARCH_ADDR seemingly being replaced by a differently-named constant, L4RE_RM_F_SEARCH_ADDR, it appears that such a value for the flags is insufficient and that additional rights flags might be required.
If I omit such rights flags, I get the L4_ENOENT error value, but this worked before. So, I think I may have misunderstood the behaviour of the function. Or are there now additional constraints imposed by the region manager that prevent any inappropriate accesses from bothering the dataspace? (My dataspace does test the flags on map requests against the rights supported by the dataspace itself.)
Another difference that I see between the old and the new is in the flags used for map requests sent to dataspaces. In the old distribution, there were these definitions (in pkg/l4re-core/l4re_c/include/dataspace.h):
L4RE_DS_MAP_FLAG_RO = 0, L4RE_DS_MAP_FLAG_RW = 1,
It appears that map requests now use the following:
L4RE_DS_F_R = L4_FPAGE_RO, L4RE_DS_F_W = L4_FPAGE_W, L4RE_DS_F_X = L4_FPAGE_X, L4RE_DS_F_RW = L4_FPAGE_RW, L4RE_DS_F_RX = L4_FPAGE_RX, L4RE_DS_F_RWX = L4_FPAGE_RWX,
I think the actual values involved here are different, but I imagine that since everything should be manipulating values derived from these definitions (as opposed to maintaining separate definitions of the flags), no incompatibility would normally be observed. But the apparent lack of conservatism surprised me slightly.
Anyway, if anyone has any insight into why the attach operation behaviour is different, I would very much appreciate it!
This behavior was introduced by the following commit in 2019:
https://github.com/kernkonzept/l4re-core/commit/81edd6119c45be6f1448a5535b13...
New dataspace and region map APIs
The new APIs allow 64bit offsets and size of dataspaces also on 32bit architectures. And have a clean and type-safe dataspace flags and region flags model including execute rights and the possibility of execute-only pages and so on.
Change-Id: I77273a5bb93c9891bca4f848c9b17db332b1b72a
In general, you must specify the access rights of the attached region explicitly now, otherwise the rights will be --- (empty) and it will not be possible to access the region. Previously the default was RW access.
This commit broke backwards compatibility in exchange for the benefits described in the commit message. We modified all our repositories to reflect this change back in 2019, but obviously you need to make adaptations to your own code yourself.
Cheers, Jakub
Jakub,
Thanks for following up!
On Friday, 27 August 2021 09:20:35 CEST Jakub Jermář wrote:
On 8/27/21 1:45 AM, Paul Boddie wrote:
Anyway, if anyone has any insight into why the attach operation behaviour is different, I would very much appreciate it!
This behavior was introduced by the following commit in 2019:
https://github.com/kernkonzept/l4re-core/commit/81edd6119c45be6f1448a5535b13 78fbc9ce89b9
New dataspace and region map APIs
The new APIs allow 64bit offsets and size of dataspaces also on 32bit architectures. And have a clean and type-safe dataspace flags and region flags model including execute rights and the possibility of execute-only pages and so on.
Change-Id: I77273a5bb93c9891bca4f848c9b17db332b1b72a
That might seem like a while ago, but I put off migrating to the GitHub repositories for some time, partly due to issues I was having with my increasingly ancient system (it wasn't reliably computing SHA1 digests and thus Git was very unhappy), partly due to inertia and having a stable code base to work with, although I'm obviously having to catch up now.
In general, you must specify the access rights of the attached region explicitly now, otherwise the rights will be --- (empty) and it will not be possible to access the region. Previously the default was RW access.
Is this to expose the rights more obviously to the client, make it "promise" to only access pages in a certain way, and to save the region manager the trouble of sending requests to the dataspace that will only end up being refused?
My workaround for now will be to request read/write access, given that I am merely providing filesystem content to programs, but I guess that if I were to have my dataspaces providing the content of executables, I would need the client program to indicate read/execute access, perhaps. (I'm not at that stage, yet: it's been quite a learning experience.)
This commit broke backwards compatibility in exchange for the benefits described in the commit message. We modified all our repositories to reflect this change back in 2019, but obviously you need to make adaptations to your own code yourself.
Sure. Thanks for confirming what I suspected!
Paul
On 8/27/21 11:18 PM, Paul Boddie wrote:
On Friday, 27 August 2021 09:20:35 CEST Jakub Jermář wrote:
On 8/27/21 1:45 AM, Paul Boddie wrote:
Anyway, if anyone has any insight into why the attach operation behaviour is different, I would very much appreciate it!
This behavior was introduced by the following commit in 2019:
https://github.com/kernkonzept/l4re-core/commit/81edd6119c45be6f1448a5535b13 78fbc9ce89b9
New dataspace and region map APIs The new APIs allow 64bit offsets and size of dataspaces also on 32bit architectures. And have a clean and type-safe dataspace flags and region flags model including execute rights and the possibility of execute-only pages and so on. Change-Id: I77273a5bb93c9891bca4f848c9b17db332b1b72a
That might seem like a while ago, but I put off migrating to the GitHub repositories for some time, partly due to issues I was having with my increasingly ancient system (it wasn't reliably computing SHA1 digests and thus Git was very unhappy), partly due to inertia and having a stable code base to work with, although I'm obviously having to catch up now.
In general, you must specify the access rights of the attached region explicitly now, otherwise the rights will be --- (empty) and it will not be possible to access the region. Previously the default was RW access.
Is this to expose the rights more obviously to the client, make it "promise" to only access pages in a certain way, and to save the region manager the trouble of sending requests to the dataspace that will only end up being refused?
This was more like we added support for non-executable data mappings and while we were at it we also used that opportunity to fix the interface systematically. For example, the flags now have each their own type. Before they were all unsigned int's or something like that and so it was easy to pass a constant of a wrong type around and not be yelled at by the compiler.
Cheers, Jakub
l4-hackers@os.inf.tu-dresden.de