[E-Lang] Summary for Practical Programming
Mon, 5 Feb 2001 12:42:02 -0000
> At 04:35 AM Saturday 2/3/01, Tyler Close wrote:
> >> >It follows that everyone also agrees that the
> capability model is
> >> >theoretically sound.
> >By "theoretically sound" I meant that the model can enforce the
> >prohibitions that it expresses.
> Strictly speaking then, we need to admit that no actual capability
> implementations are, by this definition, theoretically
> sound. Capabilities
> allow the *expression* of full confinement by lack of capability
> connectivity, since causality is only *supposed* to flow
> along capabilities.
> However, in actual capability implementations, this only
> perfectly confines
> capabilities, not bits, since bits can be wall banged. Capability
> programmers on such platforms must understand this extra
> channel of unauthorized causality. The possibility of
> bandwidth limits does
> not change this conclusion.
Agreed. How annoying.
Do we have a list of the walls in a capability system that can be
Off-hand, the only one I can think of is the CPU. The confined code
spins the CPU for different amounts of time in order to broadcast the
outgoing bits. The unconfined code then tries to measure the use of
the CPU to read the bits.
Could this be solved by placing a maximum on the number of
instructions that can be executed as the result of processing a
message taken from the inbound message queue? Exceeding the limit
results in something similar to an "Out of Memory" error. If this
maximum was chosen such that it was small enough that variations from
zero to the maximum were too small to be measured by the unconfined
code, then the outbound channel would be closed. Using such a maximum
also seems to be congruent with the goals of a multi-processing
system. It could also help with debugging and performance analysis.
The question is, would the maximum be large enough so as not to be
noticed by non-hostile, working code?