NOVA: remote revoke

[Norman Feske]

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

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth