NOVA: remote revoke

Udo Steinberg udo at ...121...
Fri Jul 20 17:06:34 CEST 2012


-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlAJc/oACgkQnhRzXSM7nSkbMwCfZrx8oJO8JI2qDNV36EOBgdqg
WboAnj8SxF8RRjtd9h2pGaTav7vdzI6A
=orvd
-----END PGP SIGNATURE-----


More information about the users mailing list