[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Opaque storage
From: |
Pierre THIERRY |
Subject: |
Re: Opaque storage |
Date: |
Wed, 10 Jan 2007 17:59:45 +0100 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
Scribit Marcus Brinkmann dies 10/01/2007 hora 09:15:
> This "destined to S" in your proposal appears to be exactly the
> tagging that I proposed. Don't you think so?
As I said, no, and to avoid any ambiguity in my scenario, I'll resketch
it with details of methods invoked. I'd like to know if you still see
some kind of tagging in this version. I omit in this scenarion
capabilities about space banks in general because I think they would
clutter the content instead of adding clarity. But all createYield()
invocations should take a capability to a sub space bank created for
that purpose as payload, so that instantiator process can destroy the
instantiated process if needed.
I precise that I'd like to know where you see tagging of *processes*,
that is where identity of processes is used by another process to take a
decision. I believe that identity of processes doesn't even appear in
this scenario.
I shall try to develop any part of the scenario where you see tagging
(to try to show that no tagging takes place).
We consider four processes:
- A, the main subject of the scenario,
- Ctr(B), a constructor for a process with unknown code, possibly
hostile,
- Ctr(G), a constructor for a trusted guard process used to implement a
reference monitor,
- S, which is a trusted service using opaque storage from it's clients.
A has initially three capabilities:
- s0 to a facet of S implementing the service,
- cb0 to a facet of Ctr(B) with only the createYield() method,
- cg0 to a facet of Ctr(G) with only the createYield() method,
The goal for A is to instantiate and use a process B form Ctr(B) that
sometimes needs access to service S without giving it authority to use
opaque storage. Note that opaque storage here could be replaced by any
other activity, namely by any capability to any process (could be I/O,
time, randomness, etc.).
1. A invokes cg0.createYield() and receives a capability g0 to the newly
instanciated process G.
2. A creates a capability a0 to a facet of itself implementing the
protocol needed by B.
3. A invokes g0.createProxyCap(a0) and receives a capability g_a0 to G.
4. A invokes cb0.createYield(g_a0). The process B is instantiated with
g_a0 as an initial capability.
5. At some point, B needs access to S, and as part of it's protocol,
invokes g_a0.giveMeAccessToService()
- G invokes a0.giveMeAccessToService()
- A creates a capability x0 to a facet of B's sub space bank
allowing opaque storage
- A invokes g0.classifyCapAsDangerous(x0), G stores the x0
capability along with a newly created no-op capability g_x0 in
it's map
- A replies to G with (s0 x0)
- G doesn't find s0 in it's map and create a proxy capability g_s0,
finds x0 in it's map, and thus replies to B with (g_s0 g_x0)
6. B creates a capability b0 to some of it's data to be consumed by S
7. B invokes g_s0.useService(g_x0, b0)
- G finds g_x0 in it's map, doesn't find b0 in it's map, and thus
invokes s0.useService(x0, b0)
Precisely,
Pierre
--
address@hidden
OpenPGP 0xD9D50D8A
signature.asc
Description: Digital signature
- Opaque storage, (continued)
- Opaque storage, Pierre THIERRY, 2007/01/09
- Re: Opaque storage, Marcus Brinkmann, 2007/01/09
- Re: Opaque storage, Pierre THIERRY, 2007/01/09
- Re: Opaque storage, Marcus Brinkmann, 2007/01/10
- Re: Opaque storage, Alan Grimes, 2007/01/10
- Re: Opaque storage, Pierre THIERRY, 2007/01/10
- Re: Opaque storage, Anton Tagunov, 2007/01/10
- Re: Opaque storage, Pierre THIERRY, 2007/01/10
- Re: Opaque storage,
Pierre THIERRY <=
- Re: Opaque storage, Marcus Brinkmann, 2007/01/10
- Re: Opaque storage, Pierre THIERRY, 2007/01/10
- Re: Opaque storage, Marcus Brinkmann, 2007/01/11
- Re: Opaque storage, Pierre THIERRY, 2007/01/11
- Re: Alternative network stack design, Tom Bachmann, 2007/01/08
- Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack, Jonathan S. Shapiro, 2007/01/07
Re: Potential use case for opaque space bank: domain factored network stack, Ludovic Courtès, 2007/01/15