NOVA: remote revoke

[Alexander Boettcher]

-----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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAJY10ACgkQqjRK9KYzJbNtTwCeILqdF1mysEMjj3spgS7LBg4t
gD8An1U3d5zN2kuhUNBCRh2cpgLx9nD/
=b+Uh
-----END PGP SIGNATURE-----