[cap-talk] Hybrid Cap Systems redux

[Jonathan S. Shapiro]

On Mon, 2008-02-18 at 10:00 -0500, David Chizmadia (Home) wrote:
> Shap,
> > - 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,
     actually viable?

  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
     design option?


shap