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

[Jed at Webstart]

At 01:36 PM 5/24/2005, Mark Miller wrote:
>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 ;).

The thought hadn't escaped my attention.  Though I think language domain 
enforcement valiant and worthwhile effort, I don't think I will be the farm 
on it for some time.

>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.

I agree.  Doesn't your constraint on the authority definition (only overt - 
seems reasonable to me) focus concern about what one might refer to as 
covert authority?  That is authorities that might be unintentionally 
available?  In fact isn't that the primary focus in defending against 
software attacks (cracking?  Viruses, etc.)?

>Eric's post about hyperthreading shows that it's becoming even harder, as 
>the hardware itself gets cleverer at trading our secrets for speedups.

I consider such covert channels as quite a way down on the list of pressing 
security concerns, a position that hasn't changed in more than 30 years.

>AFAIK, the one abstract security issue that a good OS can just get right, 
>and that is much easier using OS techniques than 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.

Hmmm.  It also seems to me that memory protection is something that is much 
easier to get right in an OS where there is a hardware domain exchange 
between processes than the way languages have to deal with software domain 
changes between active objects.  Perhaps you disagree?  Aren't some of the 
issues that you've been discussing (e.g. garbage collection issues like 
stack and heap usage) somewhat more difficult to deal with at the language 
level?

>>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.

Is that the difference you are referring to - namely that a covert 
channel's use is intentional (malicious) while a side channel's use is 
unintentional/accidental?

>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.

Sorry - I was just ignorant of the defined difference which from the above 
seems more clearly between intentional and unintentional.  With that 
definition I can see how dealing with unintentional (side channels) would 
be easier than dealing with intentional (cover channels) non-overt 
channels, though I'm still not clear on what sort of granularity you are 
referring to in:

>Preventing side channels is harder that denial of service and easier than 
>covert channels, and perhaps should be addressed at some intermediate 
>granularity.

>...t 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,

Do you mean "heap" instead of "stack" above or is my terminology perhaps a 
bit dated?  I don't think of garbage collection in terms of stack 
management (though they both have to deal with uninitialized memory).

>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.

Whew - such mechanisms seem quite a bit more iffy to me than the issues OSs 
face when exchanging between process domains.

>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.

Good luck!

--Jed http://www.webstart.com/jed/