NOVA: remote revoke

[Udo Steinberg]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 20 Jul 2012 09:37:34 +0200 Alexander Boettcher (AB) wrote:

AB> do you see any issues to extend the revoke syscall by a protection
AB> domain (pd) parameter ? Currently implicitly the current protection
AB> domain of the caller is used. With the extension the caller would have
AB> to specify explicitly the pd where the revoke operation should apply to.

Currently you don't need a PD capability to revoke capabilities from your own
protection domain. And there are situations where you, rather than your
parent, may want to revoke capabilities, e.g., cleaning up a receive window.

If you make revoke dependent on a PD capability, the consequence is that
every PD needs to hold its own PD capability. There are 5 permission bits in
a PD capability, all of which currently control creation of objects. We
would have to redefine those bits to make room for a "revoke" permission.

The permissions of a PD capability could be used for any of the following:
* creation of PD, EC, SC, PT, SM objects
* revocation of memory, I/O, objects
* more?

How would you assign those to the available 5 bits?

AB> Genode core currently revokes all memory of the client pd subject to
AB> destruction. However core has no means to make sure that references to
AB> kernel objects are freed which creation has been issued by the client
AB> pd directly using the kernel syscalls. Additionally core can't make
AB> sure to revoke any mappings of memory, i/o ports and object
AB> capabilities which the client received via other channels
AB> (services/sessions provided not by core).
AB> 
AB> The same issue also applies to NUL[0], where sigma0 can't clean up the
AB> object space of the vancouvers subject to destruction.
AB> 
AB> With the remote revoke core and sigma0 in NUL would be able to make
AB> sure that all user level references inside a pd subject to destruction
AB> can be freed.

Is destruction of a PD the only case where you see a need for remote
revocation?

Cheers,
Udo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEUEARECAAYFAlAJKK4ACgkQnhRzXSM7nSmAMgCdF/iJACYyuV/WG/ak8Zlc0Hxx
3zIAmPZY70Jve36SK3e5UuKeQ1s5yxg=
=5aDu
-----END PGP SIGNATURE-----