Re: Opaque storage

[Marcus Brinkmann]

At Wed, 10 Jan 2007 17:59:45 +0100,
Pierre THIERRY <address@hidden> wrote:
> 
> 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).

Ok, I think I understand better now.  Although the pair (s_0 x_0)
could be described as some form of tagging, I can see that this is
quite different from what I described, and in any case tagging was not
a formal term to begin with.

What you describe is essentially a virtualization of the resource
architecture.  However, this virtualization is imperfect: It only
works for "B".  If "B" wants to delegate access to the resource to a
peer, it can only delegate the dummy capability g_x0, which
unfortunately only has a meaning in the context of g_s0.  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.

So, rather than binding the service to the resource designator as in
my proposal, you are binding the user of the service to the resource
designator.  This seems less useful to me in the present scenario.  I
don't think it is necessary or desirable to prevent legitimate
delegation of a resource in this manner.

> 
> 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)

Thanks,
Marcus