[e-lang] Side Channels (was: E-on-Common-Lisp now available)
markm at cs.jhu.edu
Tue May 24 16:36:22 EDT 2005
Jed at Webstart wrote:
> I've been following this thread with interest though not with complete
> understanding - as part of checking on my general skepticism about
> language enforcement of domain boundaries between shared memory objects
Well, I suppose these issues should help reinforce your skepticism ;). Since
authority is (by definition) only about overt causality, authority boundaries
can be handled quite well at object granularity by safe language techniques.
Side channels & covert channels are hard even for a principled OS running on
bare metal. Eric's post about hyperthreading shows that it's becoming even
harder, as the hardware itself gets cleverer at trading our secrets for speedups.
AFAIK, the one abstract security issue that a good OS can just get right, and
that is much easier using OS techniques that language techniques, is denial of
service. But one can design non-E-like languages in which the language itself
provides protection from denial of service.
> The above sentence puzzles me a bit. Isn't a "side channel"
> a form of covert channel? If so how could preventing side channels be
> more difficult than preventing covert channels?
Both side channels and covert channels are forms of non-overt channels. The
difference is the intent on the part of the code doing the signaling (banging
the wall). The distinction can be fuzzy between maliciously signaling &
accidentally signaling. But here's an example where the distinction is clear:
A piece of code that's maliciously signaling through a noisy non-overt channel
might use an error correcting code to get its signal out through the noise
more effectively. An accidental signaler may signal redundantly, and so enable
the listener to use statistics to extract the signal despite the noise. But,
beyond simple redundancy, I think we can safely assume that an accidental
signaler will not accidentally encode the signal using an error correcting code.
Noise *may* therefore be much more effective at limiting the bandwidth of side
channels than of covert channels. I don't actually know.
> Are you assuming zeroing or otherwise patterning of memory in garbage
> collection as a way to minimize side channels through garbage
> collection? Sorry if I missed a mention of that.
No, nothing like that. But your question does suggest another gc-based side
Conservative garbage collectors collect a variable amount of storage depending
(among other things) on which words on the stack, if they were to be
interpreted as pointers, would be pointing at existing objects. Lacking type
information for stack frames, such a GC errs conservatively by assuming that
any such word may be an actual pointer, and retaining the object that
possible-pointer seems to be pointing at. If a called listener can cause
objects to be allocated at the locations such words may seem to point at, and
then cause a garbage collection; and if he can observe which of these objects
get collected, he may be able to obtain information about the values of int
variables of his caller that are otherwise hidden from him.
Text by me above is hereby placed in the public domain
More information about the e-lang