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