cvs commit: src/sys/amd64/amd64 mp_machdep.csrc/sys/amd64/include cpufunc.h src/sys/i386/i386 mp_machdep.c src/sys/i386/include cpufunc.h

[Nate Lawson]

Poul-Henning Kamp wrote:
> In message <4286E6A5.4030902 at freebsd.org>, Colin Percival writes:
> 
>>Nate Lawson wrote:
>>
>>>That is at best, hyperbole.
>>
>>Have you been talking to Intel lately?
>>
>>
>>> Crypto implementations which properly
>>>implement blinding or operate in constant time are not vulnerable.
>>
>>Crypto implementations which implement blinding are vulnerable.
> 
> 
> This is not just about crypto.
> 
> There are many processes which a random process should not be allowed
> to spy on in a multiuser system.
> 
> Your boss text-procssing or email program for one thing.

Every general-purpose machine has measurable timing side channels.  The 
question is merely one of bandwidth.  I can time your boss's keystrokes 
using a loop on an SMP system that runs "ps -l" looking for "ttywait" 
and get a rough measurement.  With enough samples, I can regenerate what 
he typed.  This attack against SSH-encrypted sessions has been shown to 
be effective.

My point was that FreeBSD (like most general-purpose OS) has many timing 
channels that are comparably as effective for an attacker as HTT. 
Disabling HTT does not significantly reduce an attacker's likelihood of 
success since they can just use another timing channel.  However, it 
does disable a useful feature.  Are we going to disable SMP next?

As Colin wrote in his paper, identifying, analyzing, and characterizing 
the bandwidth of all possible side channels in a system is a very 
difficult task.  There is no way to know whether or not disabling a 
given feature reduces the probability of a successful attack without 
doing this analysis.  On the other hand, the loss of functionality is 
quite certain.

Given that FreeBSD is a general-purpose OS, we need to limit timing 
channels the best we can while maintaining the widest possible feature 
support.  Since we can't completely eliminate timing channels, the best 
hope is for applications that handle secrets to do so in a 
data-independent way.  None of this is easy.

-- 
Nate