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

[Brian Fundakowski Feldman]

On Mon, May 16, 2005 at 10:18:34AM -0700, Nate Lawson wrote:
> 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.

What other side-channel attacks are going to occur against user-land
code?  Note that this explicitly excludes timing-based side-channel
attacks that are dependent on I/O, and in any case crypto operations
shouldn't be causing any I/O to happen in general because that leaves
opportunity for the interesting data to be paged out to swap.

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

It's already solved, isn't it?

-- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green at FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\