Hi,
I have been having some trouble with the Region Map interface not setting the correct permissions in my specified memory region. I am trying to replicate a similar functionality to rm_nested:
```cpp const addr_t OBJECT_SPACE_START = 0x80000000; const addr_t OBJECT_SPACE_SIZE = 0x40000000;
Genode::Env &_env; Genode::Rm_connection _rm{_env};
// To be attached to env's rm Genode::Region_map_client _obj_space{_rm.create(OBJECT_SPACE_SIZE)};
...
Region_map::Attr attributes{.size = OBJECT_SPACE_SIZE, .offset = 0, .use_at = true, .at = OBJECT_SPACE_START, .executable = true, .writeable = true};
addr_t ptr_obj = 0; env.rm() .attach(_obj_space.dataspace(), attributes) .with_result( [&ptr_obj](Genode::Env::Local_rm::Attachment &attachment) { ptr_obj = (Genode::addr_t)attachment.ptr; attachment.deallocate = false; }, [](auto) { error("couldn't attach dataspace!"); throw; });
```
I expect this code snippet to make the region at 0x80000000 to be rwx, however when I run my program with GDB I see that the permissions are ---p:
(gdb) info proc mappings Mapped address spaces:
Start Addr End Addr Size Offset Perms objfile 0x80000000 0xc0000000 0x40000000 0x0 ---p
I have also tried adding a dataspace capability to _obj_space ( before attaching it to env.rm() ) but that had no effect on the permissions:
```cpp _obj_space.attach(env.ram().alloc(OBJECT_SPACE_SIZE), attributes); ```
Any help / suggestions would be greatly appreciated as I have been stuck on this for quite a while!
Best, Rumen
P.S. The permissions are set correctly when I do:
```cpp addr_t ptr_obj = 0; env.rm() .attach(env.ram().alloc(OBJECT_SPACE_SIZE), attributes) .with_result( [&ptr_obj](Genode::Env::Local_rm::Attachment &attachment) { ptr_obj = (Genode::addr_t)attachment.ptr; attachment.deallocate = false; }, [](auto) { error("couldn't attach dataspace!"); throw; }); ```
The problem with this is that later on in my program I get an error as I need the _obj_space region map client.
Hi Rumen,
here is an example output of "info proc mappings" on base-linux:
... 0x7ffbe6e00000 0x7ffbe6e01000 0x1000 0x0 rw-s /tmp/genode-1000/ds-752 (deleted) 0x7ffbe6e01000 0x7ffbe6e10000 0xf000 0x0 ---p 0x7ffbe6e10000 0x7ffbe6e20000 0x10000 0x0 rw-s /tmp/genode-1000/ds-915 (deleted) 0x7ffbe6e20000 0x7ffbe6e40000 0x20000 0x0 ---p 0x7ffbe6e40000 0x7ffbe6e80000 0x40000 0x0 rwxs /tmp/genode-1000/ds-938 (deleted) 0x7ffbe6e80000 0x7ffbe6f00000 0x80000 0x0 rwxs /tmp/genode-1000/ds-835 (deleted) ...
The managed dataspace region goes from 0x7ffbe6e00000 to 0x7fffe6dfffff. When a dataspace is attached to the region the corresponding permissions are shown and holes between the dataspaces are shown as ---p.
Could you check if the ' _obj_space.attach()' call actually succeeded? Or if the result is different when you attach '_obj_space' to 'env.rm()' first and then the dataspace to '_obj_space'?
Christian
Hi Christian,
[When a dataspace is attached to the region the corresponding permissions
are shown and holes between the dataspaces are shown as ---p.]
The weird thing is that my whole region (size of 0x40000000) is marked as a hole.
[Could you check if the ' _obj_space.attach()' call actually succeeded?]
Yes I think the issue is here. I tried attaching a size of 0x40000000 and 50. Both threw the error: "Error: Region_map_mmap::attach: dataspace does not fit in sub RM session". Which doesn't make sense since I created _obj_space with a size of 0x40000000.
Also, is this attachment necessary? It is not used in the rm_nested code (lines 247-259): https://github.com/genodelabs/genode/blob/f1e85c0db8023ce481a40f85d4cba03f3d....
Thanks for the help.
Best, Rumen
________________________________________ From: Christian Prochaska christian.prochaska@genode-labs.com Sent: Thursday, July 24, 2025 5:29 PM To: users@lists.genode.org Subject: Re: Region Map's Permission Difficulties
CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi Rumen,
here is an example output of "info proc mappings" on base-linux:
... 0x7ffbe6e00000 0x7ffbe6e01000 0x1000 0x0 rw-s /tmp/genode-1000/ds-752 (deleted) 0x7ffbe6e01000 0x7ffbe6e10000 0xf000 0x0 ---p 0x7ffbe6e10000 0x7ffbe6e20000 0x10000 0x0 rw-s /tmp/genode-1000/ds-915 (deleted) 0x7ffbe6e20000 0x7ffbe6e40000 0x20000 0x0 ---p 0x7ffbe6e40000 0x7ffbe6e80000 0x40000 0x0 rwxs /tmp/genode-1000/ds-938 (deleted) 0x7ffbe6e80000 0x7ffbe6f00000 0x80000 0x0 rwxs /tmp/genode-1000/ds-835 (deleted) ...
The managed dataspace region goes from 0x7ffbe6e00000 to 0x7fffe6dfffff. When a dataspace is attached to the region the corresponding permissions are shown and holes between the dataspaces are shown as ---p.
Could you check if the ' _obj_space.attach()' call actually succeeded? Or if the result is different when you attach '_obj_space' to 'env.rm()' first and then the dataspace to '_obj_space'?
Christian _______________________________________________ users mailing list -- users@lists.genode.org To unsubscribe send an email to users-leave@lists.genode.org Archived at https://lists.genode.org/mailman3/hyperkitty/list/users@lists.genode.org/mes...
Hi Rumen,
I tried your code snippets and attaching the RAM dataspace worked for me with these attributes:
Region_map::Attr ram_ds_attributes{.size = OBJECT_SPACE_SIZE, .offset = 0, .use_at = true, .at = 0, .executable = true, .writeable = true}; _obj_space.attach(env.ram().alloc(OBJECT_SPACE_SIZE), ram_ds_attributes)
0x80000000 0xc0000000 0x40000000 0x0 rwxs /tmp/genode-1000/ds-73 (deleted)
On 24.07.25 22:52, Rumen Mitov wrote:
Also, is this attachment necessary? It is not used in the rm_nested code (lines 247-259): https://github.com/genodelabs/genode/blob/f1e85c0db8023ce481a40f85d4cba03f3d....
The attachment is not necessary, but without it the region is just reserved with permissions ---p and accessing it should trigger a page fault. Handling the page fault in the component or attaching additional nested region maps doesn't seem to be supported on base-linux, though, so you'd need to use a different kernel for that.
Christian