NOVA: remote revoke

Norman Feske norman.feske at ...1...
Mon Jul 23 14:19:31 CEST 2012

Hi Udo,

> 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.

that's what I'm after.

> 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.

>From Genode's point of view, this would be perfectly fine. The one who
possesses a PD capability is on power to control the PD. Only core
should possess PD capabilities. There is no reason to hand out PD caps
to other processes. However, in order to enable processes to revoke
caps from their own PD (i.e., receive windows), core might hand out a
limited (revoke-only) PD cap to the respective process. Alternatively,
there could be a 'revoke_local' variant of the syscall that uses the
caller's PD as implicit argument. Personally, I like the latter
variant slightly better because it alleviates the need to attach
permission bits to PD caps and spares core an interface for telling
each process its corresponding PD cap.

> 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.



Dr.-Ing. Norman Feske
Genode Labs ·

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

More information about the users mailing list