NOVA: remote revoke

[Udo Steinberg]

On Fri, 20 Jul 2012 17:54:18 +0200 Norman Feske (NF) wrote:

NF> Now the recursive revoke of NOVA kicks in and revokes the
NF> mappings in the process. But unfortunately, it revokes the mapping in
NF> all other processes that use the same ROM module, too. So all other
NF> processes need to fault-in the ROM module again.

So you'd need something like a "directed revoke" feature. We had something
like that in Fiasco-V2, where you could do an "unmap without self" and
additionally specify a task number. Only child mappings for that task and
its children would be removed. In the NOVA case, you'd specify a PD
capability instead of a task number.

NF> One possible solution would be to remap the ROM module for each client
NF> within core and hand out the remapped addresses when handling the
NF> client's respective page faults. But this would pollute the limited
NF> virtual address space of core.

Right.

NF> On kernels that feature remote revoke of memory such as OKL4, both
NF> scenarios are strikingly simple to come by: Simply unmap the virtual
NF> region in the process' address space. That's it.

This raises some security concerns though. Currently a [great][grand]parent
can only revoke mappings that are in its own mapping tree. It cannot revoke
anything from unrelated mapping trees and thus cannot interfere with other
pagers. What you are suggesting is giving someone with a PD capability full
control over the address-space of a remote PD. This makes the PD capability
a very powerful token.

NF> The bottom line is that the implementation of Genode's core on NOVA
NF> would greatly benefit from a remote-revoke facility for memory. For
NF> kernel objects other than memory and I/O, a selective remote revoke is
NF> not needed. Destructing a PD should implicitly revoke everything
NF> within the PD.

No doubts about the benefits and I think it would not be too hard to add
that feature. The question about the capability remains though. What exactly
authorizes that operation: a PD capability with what permissions?

Would a "directed revoke" suffice for your purposes? Basically a "revoke
the CRD and only in this child PD" operation.

Cheers,
Udo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.genode.org/pipermail/users/attachments/20120720/111a583e/attachment.sig>