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-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.