[cap-talk] Hybrid Cap Systems redux

David Chizmadia (Home) chizmadia at comcast.net
Mon Feb 18 10:00:04 EST 2008


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".

>   It follows that there is no "one size fits all"
>   algorithm to implement a membrane. It seems likely that there is no
>   "one size fits most" policy. In consequence, it does not seem likely
>   that the substitution and enforcement logic of a membrane can be
>   performed sensibly by a microkernel-style operating system.

     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.

> - 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... :-(

>   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.

-DMC


More information about the cap-talk mailing list