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

[Jeff Roberson]

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.
>
> >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?
>
> How useful is HTT on FreeBSD?  FreeBSD does not have a HTT-aware
> scheduler at present and I don't believe there are even any plans to
> make either scheduler HTT-aware.  Without this, you only gain a benefit
> if you are running fairly specific workloads.

The statement about schedulers is not entirely true.  ULE has lots of
special case code for HTT, and 4bsd even has a small amount.  In any event
it's hard to prevent general purpose workloads from slowing down with htt.
At one point ule was certainly as fast with htt as without, but I believe
there are many bugs that prevent us from taking real measurements at the
moment.

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.

>
> Peter
>