Re: Forward: some thoughts about map vs. copy vs. membranes

At Wed, 05 Sep 2007 14:48:40 -0400,
"Jonathan S. Shapiro" <[email protected]> wrote:
> 
> On Wed, 2007-09-05 at 19:22 +0200, Marcus Brinkmann wrote:
> > It is worth repeating the difficulty in implementing a generic
> > membrane: If a membraned capability is fetched through a membraned
> > capability, the lifetime of that capability is now generally bound by
> > two membranes.
> 
> Unfortunately, it is worse than this. If a capability is returned across
> a membrane boundary by an operation of the form:
> 
> 	cresult = c0->method(data args, c0, c1, ..., cn)
> 
> then the lifetime of cresult is bounded by the lifetimes of c0 .. cn.
> While a binary tree can express this dependency, the logical dependency
> chain is not restricted to two inputs per output. The problem is that we
> cannot know at the time of membrane formation which capability in {c0,
> cn} will die first.

I do agree that the lifetime of a membraned capability is not
necessarily bound by one or two membranes.  The number "2" above was
only an example.  It is easy to construct an arbitrary number of
dependencies by repeating the above operation, adding one more
membrane dependency at each iteration.

I think the example you are bringing up is interesting.  However, I am
not sure why you think that cresult in your example should generally
be limited by any other capability than c0.  There are peculiarly few
operations involving capabilities as arguments, and even less return
capabilities, so use cases to analyze are rare.  Off the top of my
hat, I can think of two:

One example is the Hurd auth protocol, and in that case it would be a
mistake to limit the lifetime of the authenticated capability by the
lifetime of the rendezvous capability.  The other example are calls to
a server which carry a reply capability, and of course there also the
lifetime of any returned capabilities should not be limited by the
lifetime of the reply capability.  I am not saying that it never
happens that cresult should be limited by some (or even all) of c1,
..., cn.  But it does not seem universal.

> > It's easy to show that L4 X.2 implements membrane semantics...
> 
> Because membrane injection is not restricted to cases of delegation,
> membranes require full interposition of all invocations in general.
> In order for L4 kernel to implement membrane semantics, it would be
> required to do full causal dependency tracking across IPC.
> The L4 map primitive does implement a restricted sub-case of membrane
> semantics, but this sub-case is not useful.

Well, yes.  But I didn't realize until recently that L4 X.2 memory
mapping implements membrane semantics rather than what we refered to
as "map" in the past.  I think that alone already is an important
point that helps to clarify past discussions, hence my note.  It might
also help to explain recent divergent evolutions of the L4 design.
(The restrictive sub-case can be generalized consistently in different
ways to endpoints, and the group in Dresden and Sydney explore
different possibilities).

Thanks,
Marcus