[cap-talk] Storage allocation (was: Re: Use-case: hybrid capability systems)

[Jed Donnelley]

On 2/8/2008 1:57 PM, Jonathan S. Shapiro wrote:
> On Fri, 2008-02-08 at 12:45 -0800, Jed Donnelley wrote:
>> Regarding the first, the amount of storage involved, let me say
>> two things:
>>
>> 1.  If allocating storage for intermediate capability communication
>> is an insolvable problem, then this is serious indeed.  Every
>> membrane mechanism from vats back to DCCS have the problem of
>> allocating storage for every capability that passes through
>> them.
> 
> I agree, and yes, it is a serious problem. SOME of the membrane patterns
> we have discussed can evade the issue with a capability-exchange
> protocol,

Could you either explain or provide a reference on the
"capability-exchange protocol"?  The only references I
was able to find seem to focus on an apparently unrelated
networking area.  I'm interested to know what you mean
by that term.  The only reference I was able to find on
cap-talk was from you in:

http://www.eros-os.org/pipermail/cap-talk/2007-July/008491.html

when you said:

"After some discussion among the L4 crowd, it was determined that a
capability exchange protocol with the target object server could be used
to dis-entangle the revocation chain that is introduced by the "map"
operation. The difficulty with this protocol is that the object server
is not in a good position to know the sender's intent -- that is: does
the sender want the capability to be unchainable?"

Pulling in the L4 reference I was able to find some discussion
of a "capability exchange server", but still not enough for
me to tease out the basic concept.  E.g.:

http://osdir.com/ml/os.hurd.l4/2005-10/msg00360.html

and a few others along the same lines.  Perhaps you could
explain the basic idea - e.g. how it differs from something
like MarkM's vat mechanism or the DCCS or the Mach Net
server, or provide a pointer?

> but only if the membranes collaborate, which requires them to
> be part of the systemwide TCB.

 From my perspective it just depends on how the membrane
is used.  In the case of something like the vat/DCCS
mechanism, any object invocations that communicate
off system (on the network, off the base descriptor
TCB) will have to use the mechanism and therefore
will be able to participate in the resource sharing.
In this case there is behind the scenes "collaboration"
between different capabilities that are supported
by the same infrastructure and can therefore of
course use a common shared resource pool (e.g.
a shared cache).

Still, local capability invocations don't need to
go through the vat/DCCS, so I don't think such
a mechanism should really be considered part of
the Trusted Control Block.  Certainly very important,
but not quite universally trusted.

I think the same would apply to any other
membrane such as Horton.  It just depends on
how much of the capability communication requires
ID to ID delegation support (control).  Perhaps
all or perhaps little - that seems to me to
be a design trade-off.  If the mechanism is
required for all transactions - well, it's
required, whether formally considered part of
the TCB or not, in some sense I would say it
is trusted, so perhaps there we agree.

--Jed  http://www.webstart.com/jed/