Re: Opaque storage
Pierre THIERRY <[email protected]>
| Newsgroups | gmane.os.hurd.l4 |
|---|---|
| Message-ID | <[email protected]> |
Scribit Marcus Brinkmann dies 10/01/2007 hora 18:56:
> A process C which communicates with B on a peer-to-peer basis can not
> make use of g_s0, as it lacks this context (and probably wouldn't
> trust it anyway), thereby making resource sharing unfeasible.
OK, let's describe it. I'll renumber my previous steps as 1-1 to 1-7, to
be able to refer to them while numbering independently other parallel
branches of steps.
Remember that A has total control on the initial capabilities initially
given to B, and you don't specify here how B would acquire a capability
to C and how this latter has been instantiated and authority it has
already been granted. I'll take the assumption that in any way, B has a
capability c0 to a facet of C implementing the desired service.
If my description is inadequate, please specify exactly authority and
state of C.
We're at the state where B has g_s0 and g_x0 (after step 1-5), and it
needs antoher service process C to do something that needs access to S.
As part of C's protocol, it's client has to provide the opaque storage
that S will use.
2-1. B creates a capability b1 to some of it's data to be consumed by C
2-2. B invokes c0.doSomethingWithService(g_s0, g_x0, b1)
2-3. C creates a capability c1 to some of it's data to be consumed by S
2-4. C invokes g_s0.useService(g_x0, c1)
- G finds g_x0 in it's map, doesn't find c1 in it's map, and thus
invokes s0.useService(x0, c1)
Where do you see infeasibility? Obviously C is able to use S, but not
opaque storage itself. If it communicates with B on a peer-to-peer
basis, then it's just behind the reference monitor. Still, G has no
knowledge of the identities of the processes involved.
Easily,
Pierre
--
[email protected]
OpenPGP 0xD9D50D8A
_______________________________________________
L4-hurd mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/l4-hurd
signature.asc
(application/pgp-signature, 189 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFpTKZxe13INnVDYoRAjIoAJ49yVMlzDSUVpi8Q/KULzTeiNrD6gCg5bcq 04OOon9qhl/RsV4ZjhRE2os= =hUcI -----END PGP SIGNATURE-----