[e-lang] Side Channels (was: E-on-Common-Lisp now available)

[Mark Miller]

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 
> (methods).

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 
channel possibility:

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

     Cheers,
     --MarkM