Subj : Timing side channels (was: [.NET] Volatile Fields)
To   : comp.programming.threads
From : David Hopwood
Date : Sat Sep 17 2005 03:55 pm

Joe Seigh wrote:
> David Hopwood wrote:
>> Joe Seigh wrote:
>>> Cool Guy wrote:
>>>
>>>> My confusion arises from the fact that only *one* of those fields is
>>>> volatile in the example linked from the OP, and not *both* of them,
>>>> which
>>>> leads me to believe that the one field that isn't volatile could be
>>>> read/written from/to the cache instead of from/to main memory and thus
>>>> the code isn't thread-safe.
>>>
>>> If that was true then you could detect the presence of cache.  But you
>>> can't detect the presence of cache by definition so it must not be
>>> true.
>>
>> You *can* detect the presence of cache (even though it is a transparent
>> optimization). Its presence affects which of the behaviours that are
>> allowed by the nondeterministic memory model can actually occur on a
>> given implementation. This is usually not an issue if you depend only on
>> the memory model. But note that you cannot force other software to depend
>> only on the memory model, and that can have security implications, e.g.
>> <http://www.daemonology.net/hyperthreading-considered-harmful/>.
> 
> Well, there is a performance effect which would have to be there otherwise
> there would be no reason to have cache then.

It's misleading to call timing side channels just a performance effect.
I think most PGP users or SSL server operators would raise an eyebrow if you
told them that compromise of their private key was just a performance effect,
for instance.

> I deliberately left that out to simplify things so as to not confuse the
> OP any further.  He seems confused enough.  But now that you've brought it
> up, you are now officially responsible for unconfusing the OP.  Have fun.  :)

The issue is that some optimizations can be harmless from the point of view
of correctness of a program that only relies on a particular (nondeterministic)
specification, but can still leak information that results in a security flaw.
That isn't a particularly confusing point IMHO (although it deserves to be
more widely appreciated).

-- 
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>

.