On Thu, 2007-09-06 at 05:00 +0200, Marcus Brinkmann wrote: > At Wed, 05 Sep 2007 14:48:40 -0400, > "Jonathan S. Shapiro" <[EMAIL PROTECTED]> wrote: > > > > cresult = c0->method(data args, c0, c1, ..., cn) > > 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....
I think this because the membrane that has been under discussion on cap-talk is the one in which this is the defined behavior. The problem is that the term "membrane" is being overloaded: it is both a generic term meaning "a mechanism (in our context: a process) that enforces transitive revocation policies by injecting wrappers and tracking propagation'. We have also used it to refer to an particular instantiation that implements the particular policy that I have described above. I suggest that in the future, to avoid ambiguity, we should call this the Causal Dependency Membrane. The causal dependency membrane is certainly not the only possible membrane. So: I should restate what I said about L4 implementing membranes: L4 *must not* implement membranes, because membranes embed policies concerning revocations. L4 *may* implement a useful supporting mechanism, but it is not yet clear whether that mechanism is helpful given that an application-level agent is required to define the policy in any case. Of course, there may turn out to be membranes that don't require a special policy agent because they can be implemented trivially using the kernel mechanism. The Hurd auth protocol sounds like a case where this is true. > 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 agree that making the mechanism difference clear is useful. I only wanted us to avoid drawing excessive conclusions. -- Jonathan S. Shapiro Managing Directory The EROS Group, LLC www.coyotos.org, www.eros-os.org _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
