[cap-talk] Hybrid Cap Systems redux

[Daniel Yokomizo]

On Mon, Feb 18, 2008 at 2:11 PM, Jonathan S. Shapiro <shap at eros-os.com> wrote:
> The discussion on hybrid cap systems more or less died out without
>  anyone proposing a viable solution. This strikes me as very unfortunate,
>  because it is THE problem we need to understand in order to understand
>  whether OS-based cap systems (or, indeed, cap systems in general) are
>  viable in the real world.
>
>  Let me summarize what I see as the key issues:
>
>
>  Storage Management:
>
>  - We have two schools on storage management in capability systems:
>   the garbage collection (GC) school and the explicit revocation (ER)
>   school.
>
>  - NO credible designs have been put forward for the membrane pattern
>   that tolerate explicit revocation.
>
>   If you have a counterexample, please either (a) fully describe the
>   mechanism, or (b) provide a URL to a *single* message in which the
>   mechanism is described. Pointing me at an email thread is not helpful;
>   in the absence of synopsis, the discussions on this topic have been
>   too discursive for me to be able to follow them even when they
>   were fresh in my memory.

AFAICS this <http://lambda-the-ultimate.org/node/1625#comment-20016>
should be a solution for it. It came in a discussion about revokable
membranes in a static typed language. There are other solutions in the
discussion (both above and below). The solution is given in the
context of functional programming, we can extend it to an object
oriented setting by using the appropriate encodings/translations.

>  - NO credible designs have been put forward for GC-based system that
>   evade storage denial of resource attacks.
>
>  Performance:
>
>  - We appear to have two qualitatively different mechanisms related
>   to membranes:
>
>      1. Wrappers/Forwarders. These are destroyable, but do not
>         otherwise enforce a policy on the operations that are performed.

IIUC the above solution can be extended with a policy function that
decides how to handle each request.

>      2. General substitution engines (GSE), wherein some policy is
>         implemented through selective capability substitution and
>         proxying.
>
>  - 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. 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.
>
>  - 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.
>
>   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.
>
>
>  Reactions and corrections appreciated.
>
>
>  shap

Best regards,
Daniel Yokomizo.