-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 20 Jul 2012 15:55:44 +0200 Alexander Boettcher (AB) wrote:
AB> So, what I'm suggesting is: AB> AB> Those who have the PD cap are allowed to issue any kind of revoke AB> operation. (I would rather have a bit for each right but it seems not AB> be possible without redesign of the current interface)
So what I'm asking is the following...
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 remotely create objects in a PD for which you have a capability with adequate permissions. We could extend that interface to be able to remotely destruct objects the same way, using the same permission bits of the PD cap.
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 capability alone (with any combination of permission bits set) would allow for remote revocation of memory and/or I/O. Likewise, it's very ugly if you would specify a null capability for that purpose.
AB> The other option of course would be that the kernel takes care of the AB> destruction of all objects when a PD should be killed, for example as AB> soon as all user level available references to the PD object cap are AB> revoked. Do you want to manage it rather in kernel instead at user AB> level layer ?
I would go for the option of destroying the PD cap if you want to get rid of everything in a PD. If you want to selectively revoke stuff, then that's not going to be an option, because you obviously wouldn't want to destroy the whole PD.
Cheers, Udo