Date: Mon, 16 May 2005 05:41:23 -0400 (EDT) From: Jeff Roberson <jroberson@chesapeake.net> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: Nate Lawson <nate@root.org> Subject: Re: 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 Message-ID: <20050516053818.E53620@mail.chesapeake.net> In-Reply-To: <20050516080031.GD34537@server.vk2pj.dyndns.org> References: <97079.1116154766@critter.freebsd.dk> <4287AD84.6070600@root.org> <20050516080031.GD34537@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050516053818.E53620>