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.
Yes.
Cheers Norman