Hi Udo,
Is there a use case where you want to selectively revoke stuff in a remote PD (as opposed to revoking everything in a remote PD). Currently you can
from the top of my head I cannot think of any use case where a remote selective revoke of capabilities would be beneficial. But revoking everything within the PD when the PD is destroyed is desired.
That would not cover remote revocation of memory and I/O ports though. And from an interface perspective, it is quite ugly if possession of a PD
For memory and I/O, I would greatly appreciate a remote revoke function.
Just as an illustration, imagine that there is one ROM module handed out to many programs. (i.e., a shared library). Now, one program detaches the ROM dataspace from its local address space by invoking core's 'Rm_session::detach()'. In order to unmap the virtual pages from the program's address space where the ROM module was attached, core needs to determine the corresponding core-local address of the ROM module and then revoke that address range from core's address space. Now the recursive revoke of NOVA kicks in and revokes the mappings in the process. But unfortunately, it revokes the mapping in all other processes that use the same ROM module, too. So all other processes need to fault-in the ROM module again.
One possible solution would be to remap the ROM module for each client within core and hand out the remapped addresses when handling the client's respective page faults. But this would pollute the limited virtual address space of core.
The problem is further amplified when using nested dataspaces. When unmapping such nested dataspace on NOVA, core needs to traverse the (tree of) nested dataspaces to search for leaf dataspaces (physical memory objects) and revoke each single leaf individually. This is a complicated and potentially long-taking operation (and hence, not implemented as of now).
On kernels that feature remote revoke of memory such as OKL4, both scenarios are strikingly simple to come by: Simply unmap the virtual region in the process' address space. That's it.
A further benefit of a remote revoke of memory would be that core could hand out memory to processes directly from the physical address space (rather than core's virtual address space). The need to have all used memory mapped in core would simply vanish and the size of the virtual address space of core would not pose a limitation of the usable memory outside of core anymore. Right now, core cannot do that because it could not regain control over the resources once handed out. Remote revoke would be the key. Alleviating the core-local mapping of all memory objects might also have a positive effect for the consumption of kernel memory.
The bottom line is that the implementation of Genode's core on NOVA would greatly benefit from a remote-revoke facility for memory. For kernel objects other than memory and I/O, a selective remote revoke is not needed. Destructing a PD should implicitly revoke everything within the PD.
Cheers Norman