-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 20.07.2012 11:45, Udo Steinberg wrote:
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
Yes, this is already the current situation. In Genode as NUL currently every PD has to hold its own PD cap for various other system calls.
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?
I would not re-assign any bits. Of course, extra right bits would be super generic to have it for the revoke operation, but it seems to be more a interface limitation problem than a hard design problem. (If there would be enough bits we would probably not discuss about it.)
If we look as how the PD cap is used currently, only the parent (Genode:core resp. NUL:sigma0) hold the PD cap with full rights. On the other hand the children have the PD cap (partially with restricted rights) solely to be able to invoke various system calls like create_sm, create_pt, create_ec, create_pd ... because it is required to have it.
Beside that there seems to be, at least in Genode as in NUL, no need nor use case to propagate the PD around in the system where all the additional right bits for revoke would be beneficial.
Or do you see such a use case for now?
To come back to the original problem. If you don't want that a child have to provide a cap for local revokes, then we just could stay with the current situation as it is currently.
* If the child provides _no_ or a NULL-CAP than the implicit available PD cap of the calling/local PD is used.
However,
* If the caller provides a valid PD cap, then the revoke operation is applied for the valid PD domain.
So, what I'm suggesting is:
* Those who have the PD cap are allowed to issue any kind of revoke operation. (I would rather have a bit for each right but it seems not be possible without redesign of the current interface)
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?
For now it is the only use case where I don't know of how to solve it with the current mechanism provided by the kernel. It would also make life easier to selectively revoke shared memory between children without revoking it from all children (as currently done in Genode according to Norman) or to have intermediate mappings in core to be able to revoke selectively (not done currently), however is not required.
The other option of course would be that the kernel takes care of the destruction of all objects when a PD should be killed, for example as soon as all user level available references to the PD object cap are revoked. Do you want to manage it rather in kernel instead at user level layer ?
Don't know what you rather prefer.
Cheers,
Alex.