The recent Hyper-Threading vulnerability announcement [story [1]] was discussed [2] on the Linux Kernel Mailing List [3]. Reactions were mixed. Andi Kleen suggested, "disabling HT for this would the totally wrong approach, like throwing out the baby with the bath water." Alan Cox [interview [4]] commented that it was a moot issue, "HT for most users is pretty irrelevant, its a neat idea but the benchmarks don't suggest its too big a hit."
Regarding the usefulness of Hyper-Threading, Linus Torvalds had a different opinion, "HT is _wonderful_ for latency reduction." He went on to add, "why people think 'performace' means 'throughput' is something I'll never understand. Throughput is _always_ secondary to latency, and really only becomes interesting when it becomes a latency number." He then went on to discuss the proposed vulnerability:
"As to the HT 'vulnerability', it really seems to be not a whole lot different than what people saw with early SMP and (small) direct-mapped caches. Thank God those days are gone.
"I'd be really surprised if somebody is actually able to get a real-world attack on a real-world pgp key usage or similar out of it (and as to the covert channel, nobody cares). It's a fairly interesting approach, but it's certainly neither new nor HT-specific, [nor does it] necessarily seem all that worrying in real life."
From: Gabor MICSKO [email blocked] To: linux-kernel Subject: Hyper-Threading Vulnerability Date: Fri, 13 May 2005 07:51:20 +0200 Hi! From http://kerneltrap.org/node/5103 [5] ``Hyper-Threading, as currently implemented on Intel Pentium Extreme Edition, Pentium 4, Mobile Pentium 4, and Xeon processors, suffers from a serious security flaw," Colin explains. "This flaw permits local information disclosure, including allowing an unprivileged user to steal an RSA private key being used on the same machine. Administrators of multi-user systems are strongly advised to take action to disable Hyper-Threading immediately." ``More'' info here: http://www.daemonology.net/hyperthreading-considered-harmful/ [6] Is this flaw affects the current stable Linux kernels? Workaround? Patch? Thanks. - MG
From: Andi Kleen [email blocked] Subject: Re: Hyper-Threading Vulnerability Date: Fri, 13 May 2005 20:03:58 +0200 Gabor MICSKO [email blocked] writes: > Hi! > > From http://kerneltrap.org/node/5103 [7] > > ``Hyper-Threading, as currently implemented on Intel Pentium Extreme > Edition, Pentium 4, Mobile Pentium 4, and Xeon processors, suffers from > a serious security flaw," Colin explains. "This flaw permits local > information disclosure, including allowing an unprivileged user to steal > an RSA private key being used on the same machine. Administrators of > multi-user systems are strongly advised to take action to disable > Hyper-Threading immediately." > > ``More'' info here: > http://www.daemonology.net/hyperthreading-considered-harmful/ [8] > > Is this flaw affects the current stable Linux kernels? Workaround? > Patch? 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. Disabling HT for this would the totally wrong approach, like throwing out the baby with the bath water. -Andi
From: Alan Cox [9] [email blocked] Subject: Re: Hyper-Threading Vulnerability Date: Fri, 13 May 2005 19:35:48 +0100 > 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
From: Scott Robert Ladd [email blocked] Subject: Re: Hyper-Threading Vulnerability Date: Fri, 13 May 2005 14:49:25 -0400 Alan Cox wrote: > HT for most users is pretty irrelevant, its a neat idea but the > benchmarks don't suggest its too big a hit On real-world applications, I haven't seen HT boost performance by more than 15% on a Pentium 4 -- and the usual gain is around 5%, if anything at all. HT is a nice idea, but I don't enable it on my systems. ..Scott
From: Linus Torvalds [email blocked] Subject: Re: Hyper-Threading Vulnerability Date: Mon, 16 May 2005 10:00:20 -0700 (PDT) On Fri, 13 May 2005, Scott Robert Ladd wrote: > > Alan Cox wrote: > > HT for most users is pretty irrelevant, its a neat idea but the > > benchmarks don't suggest its too big a hit > > On real-world applications, I haven't seen HT boost performance by more > than 15% on a Pentium 4 -- and the usual gain is around 5%, if anything > at all. HT is a nice idea, but I don't enable it on my systems. HT is _wonderful_ for latency reduction. Why people think "performace" means "throughput" is something I'll never understand. Throughput is _always_ secondary to latency, and really only becomes interesting when it becomes a latency number (ie "I need higher throughput in order to process these jobs in 4 hours instead of 8" - notice how the real issue was again about _latency_). Now, Linux tends to have pretty good CPU latency anyway, so it's not usually that big of a deal, but I definitely enjoyed having a HT machine over a regular UP one. I'm told the effect was even more pronounced on XP. Of course, these days I enjoy having dual cores more, though, and with multiple cores, the latency advantages of HT become much less pronounced. As to the HT "vulnerability", it really seems to be not a whole lot different than what people saw with early SMP and (small) direct-mapped caches. Thank God those days are gone. I'd be really surprised if somebody is actually able to get a real-world attack on a real-world pgp key usage or similar out of it (and as to the covert channel, nobody cares). It's a fairly interesting approach, but it's certainly neither new nor HT-specific, or necessarily seem all that worrying in real life. (HT and modern CPU speeds just means that the covert channel is _faster_ than it has been before, since you can test the L1 at core speeds. I doubt it helps the key attack much, though, since faster in that case cuts both ways: the speed of testing the cache eviction may have gone up, but so has the speed of the operation you're trying to follow, and you'd likely have a really hard time trying to catch things in real life). It does show that if you want to hide key operations, you want to be careful. I don't think HT is at fault per se. Linus
Related Links:
- Archive of above thread [10]
- KernelTrap interview with Alan Cox [11]