Messages in this thread | | | Date | Wed, 18 May 2005 15:07:30 -0400 (EDT) | From | Bill Davidsen <> | Subject | Re: Hyper-Threading Vulnerability |
| |
On Fri, 13 May 2005, Alan Cox wrote:
> > This is not a kernel problem, but a user space problem. The fix > > is to change the user space crypto code to need the same number of cache line > > accesses on all keys. > > You actually also need to hit the same cache line sequence on all keys > if you take a bit more care about it. > > > Disabling HT for this would the totally wrong approach, like throwing > > out the baby with the bath water. > > HT for most users is pretty irrelevant, its a neat idea but the > benchmarks don't suggest its too big a hit
This is one of those things which can give any result depending on the measurement. For kernel compiles I might see a 5-30% reduction in clock time, for threaded applications like web/mail/news not much, and for applications which communicate via shared memory up to 50% because some blocking system calls can be avoided and cache impact is lower.
In general I have to agree with the "too big," but I haven't seen any indication that the hole can be exploited without being able to run a custom application on the machine, so for single users machines and servers the risk level seems low.
-- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |