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

[Nate Lawson]

Jeff Roberson wrote:
> On Mon, 16 May 2005, Peter Jeremy wrote:
>>On Sun, May 15, 2005 at 01:13:56PM -0700, Nate Lawson wrote:
>>
>>>My point was that FreeBSD (like most general-purpose OS) has many timing
>>>channels that are comparably as effective for an attacker as HTT.
>>
>>If you take the bandwidth of the timing channel into account, I don't
>>believe there are any other timing channels that come anywhere near the
>>HTT attack.  Maybe Colin has a better idea of what other timing channels
>>exist and how they compare to HTT.

See my previous email.  Even with a 1 bit per second channel, a 1024 bit 
secret would be revealed in 17 minutes.  In nearly every common use 
case, there is no difference from a security standpoint between a 
compromise taking 1 second or 17 minutes.

In light of this threat model, disabling HTT to fix timing attacks is 
similar to removing strcpy in hopes of eliminating buffer overflows. 
Sure it may be the most commonly misused function, but the attacker 
still has memcpy, strcat, sprintf, integer overflows, etc.

>>>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?
>>
> Long term for HTT, if intel keeps it implemented the way it is now, I was
> intending to only schedule threads from the same process on the second
> core.  I believe this would leave it as an optimization which will only
> effect the few cases that it is likely to help.
> 
> Anyway, I am not going to throw in my .02 on whether or not it should be
> disabled, but I will say that both schedulers have some awareness of htt.

I think making the scheduler do this is a great solution.

-- 
Nate