[E-Lang] Re: Old Security Myths Continue to Mislead

[Jonathan S. Shapiro]

> * KeySAFE: Has anyone measured the overhead of imposing a membrane between
> Domains?  Any idea how much this would cost in EROS?  The purpose of
> KeySAFE, AFAIK, was to meet Orange book criteria of high security.

I don't have access to KeySAFE, so I cannot measure that. Mediation, however
can be done by a "small" domain, so the marginal overhead reported in our
SOSP paper for large-small-large vs. large-large is probably the closest
available number.

Note, however, that this figure fails to consider creative uses of shared
memory. Every *correct* case of mediation I can think of involves one-way
information flow, which is best accomplished by a shared memory buffer,
which makes the intervention overhead essentially zero.

I have recently been reminded by my exchange with Dan to re-examine the
Hydra templates mechanism. We want something more flexible than "weak"
capabilities, because there are relevant and important definitions of
"safety" that are not about information flow. E.g. There are cases where the
nature of the mediation is: "the interface has been deemed okay for our
purposes, we must now simply do type checking in the transport." (that is:
run-time type checking). It would be very nice not to pay marginal context
switches for this, and I believe this can be achieved via a relatively
modest enhancement to the currently-proposed EROS indirector objects.

Hmm. I am concluding that there is a paper to be written on efficient
mediation strategies for capability-based operating systems.

> * Is confinement mediation?  Somewhere I think I saw someone (Jonathan?)
> refer to confinement as a case of mediation.

Perhaps I wrote this. If so, I wrote badly. I meant to say that confinement
is a precondition to mediation. Mediation is an activity by which selective
communication is permitted between two otherwise confined subsystems. If the
subsystems are not confined, it is sometimes feasible, but exceedingly
difficult, to show that the mediation path cannot be bypassed. Certainly an
information flow verification would be called for.

> Bottom line: In a capability system, the compartment/membrane pattern is
> very rarely if ever called for.  When it is, it is only needed at a
> granularity vastly larger than the individual object/protection-domain.

I agree that this is true if your software was designed for use in a
capability style. When one is trying to retrofit capability ideas to
existing OO software, it may be necessary to encapsulate more finely.

Hmm. This strongly suggests to me that there is an important difference
between OO and capability-based programming that I have not yet discovered
how to articulate clearly. If capabilities are, as MarkM argues, simply
"pure object references", then why is it that so little OO code translates
successfully into capability systems without overhaul? Is this merely a
reflection of the fact that well-encapsulated design is hard, and therefore
rarely done, or is there something more basic at work here? Anybody got a
useful framing?

Stiegler-san: since you've been describing E programming to an introductory
audience, have you any useful insights here? I haven't looked at "E in a
Walnut" (time constraints), but it is beyond credence to think that you
would successfully restrict yourself to "what to do" without discussing both
"how to" and giving some careful thought to motivating "why". Ideas?

Jonathan