[cap-talk] Hybrid Cap Systems redux
Jonathan S. Shapiro
shap at eros-os.com
Mon Feb 18 10:47:21 EST 2008
On Mon, 2008-02-18 at 10:00 -0500, David Chizmadia (Home) wrote:
> > - It appears fairly evident that a successful membrane implementation
> > must implement capability substitution, and that the substitution
> > policy is inherently dependent on the nature of the policy that the
> > membrane implements.
> I parse the English in this last sentence as "the substitution
> policy is inherently dependent on the substitution policy", which is
> somewhat tautological ;-). I going to interpret the intended meaning
> as: "the substitution policy is inherently dependent on the use
> case(s) of the object behind the membrane".
Hmm. That may be correct, but what I was thinking was: "the substitution
policy is dependent on the security and revocation-independence policies
that the membrane implements".
> For what its worth, this matches my conclusion. I believe that
> it points out a need for *very* effective tools being available for
> developing object-specific membranes. While reading this message, an
> initial hypothesis is that a CapIDL-based tool would be particularly
> useful here.
A clean IDL specification certainly helps, though static introspection
may be good enough (and in fact, may be required).
> > - It is not clear what the dynamic frequency of membrane-crossing
> > operations look like. More precisely, it is not clear what the
> > dynamic frequency of use is for membranes in the GSE category.
> ...and as with far too many of the practical question discussed
> here, for the people asking the question there is neither the time
> nor the existing infrastructure to perform the required experiments
> to get empirical data... :-(
I am not entirely convinced of that. For example, many of the membranes
that we have discussed fall into two categories:
combiners/wrappers, which clearly CAN be implemented within the OS
GSE's, but often in places where we would otherwise be using ACLs.
So it may be that we can estimate membrane-crossing frequency by
measuring the frequency and cost of ACL-testing operations in a UNIX
system, which should not be difficult to measure.
The problem I anticipate is that membranes will prove to be a generally
useful idiom, and their performance will quickly become critical.
> > Given that hardware context switch latencies are bad and continue to
> > get worse, I am *very* concerned that this class of design may
> > not be feasible in OS-based cap systems -- or at least, not within
> > the conventional design parameters of such systems.
> I think that it is important to note your caveat that the
> problem is with *OS-based* cap systems!! My current intuition is
> that there exist *language-based* system designs that could handle
> the problem within the confines of the ocap paradigm.
I agree. I further agree with Alan that the Singularity folks "missed it
by *that* much" (which seems to be a sad tradition in OS work). At the
end of the day, I am leading up to some very disturbing questions:
1. Are OS-based cap systems, where I mean "OS" in the traditional
sense, as distinct from some sort of exokernel-style thing,
2. If language-based cap systems are the way to go, how do we deal
with things like system-wide persistence?
Systems like E rely implicitly on the assumption that the size of a
VAT is less than the size of a single hardware address space.
3. If the answer is: "persistence is necessarily scoped by some
domain" Then it follows that we have a layered cap design (c.f.
E refs vs. E sturdyrefs), and the next question should be "how
shall we choose a proper granularity for such domains?" and in
particular, "is it feasible to build a system in which the largest
persistence domain is bounded by the hardware address space size?"
4. Given that a pure language approach abandons any hope for backwards
compatibility with existing programs, can we come up with a hybrid
approach in which address-space based protection remains a viable
More information about the cap-talk