Hyperthreading Considered Harmful 392
cperciva writes "Hyper-Threading, as currently implemented on Intel Pentium Extreme Edition,
Pentium 4, Mobile Pentium 4, and Xeon processors, suffers from a serious
security flaw. 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.
I will be presenting this attack at
BSDCan 2005 at 10:00 AM EDT on May 13th, and at the conclusion of my talk
I will also releasing a paper describing the attack and possible mitigation
strategies."
Sysadmins have been advised... (Score:4, Funny)
It is just an 'give me a job' attention grab (Score:2, Insightful)
question 4 in his list:
No details given... (Score:2)
granted there is nothing wrong with this guys ability in marketing. As as techie this creates two reactions in me:
Re:No details given... (Score:5, Insightful)
Now, you might not think this guy is credible and so wait for him to 'show you the code' before applying the suggested fix. That's up to you.
Details now given. (Score:4, Informative)
This is one of the best thought out, best written papers of its kind that I have read in my over thirty years of work in the engineering field.
Re:It is just an 'give me a job' attention grab (Score:5, Insightful)
If he can produce even a moderately effective proof-of-concept exploit (which apparently he has), someone with a little malicious creativity will find out a way to abuse it.
Also as a security professional, any gap, niche or irregularity in core security processes needs to be taken seriously even if nothing ever pans out in a real exploit.
As far as the attention grab, I don't begrudge the guy at all. If the exploit is bogus, he will have advertised to the world "I'm an idiot - don't hire me!". If it is valid, he has shown his worth and deserves some support.
On the other hand (Score:4, Informative)
(I'm not biased by having spent the past 7 years there)
Re:On the other hand (Score:2)
http://ed.sjtu.edu.cn/rank/2004/top500(1-100).htm [sjtu.edu.cn]
even the british don't think so:
http://www.thes.co.uk/statistics/ [thes.co.uk]
is oxford very, very good? yes. i'm visiting now, and it's a great place to be. commonly held to be the finest in the world? that's a stretch.
Re:On the other hand (Score:5, Informative)
And this isn't the first time he has come up with some interesting research [daemonology.net] that has been mentioned [slashdot.org] on Slashdot [slashdot.org] before [slashdot.org]. Sure, he seems to be a little arrogant, but with his [cecm.sfu.ca] record [cecm.sfu.ca] so [ox.ac.uk] far [ox.ac.uk], I think he's earned the benefit of the doubt here...
Re:On the other hand (Score:3, Informative)
Re:On the other hand (Score:3, Funny)
Richard: "Yeah. They're called doctors."
Re: On the gripping hand (Score:5, Insightful)
Where you get your education is immaterial. More important is what you do with it.
Right (Score:3, Insightful)
Because, of course, who needs community? People are awful. I'd much rather stay in my mom's basement with my
This ought to be interesting (Score:5, Interesting)
Re:This ought to be interesting (Score:3, Insightful)
FreeBSD: This issue affects FreeBSD/i386 and FreeBSD/amd64, and is addressed in advisory FreeBSD-SA-05:09.htt.
NetBSD: The NetBSD Security-Officer Team believes that workarounds will be suitable for the majority of our users. Since this issue is a complex one, the 'right' solution will require a larger discussion which is only possible once this issu
Re:This ought to be interesting (Score:4, Interesting)
With HT, registers for multiple threads have to reside within the same CPU, whereas with SMP, they are physically in two different chips. Perhaps the registers used by HT are not properly protected against reading by other threads. The fact that SMP code was probably reused may be the cause of the problem: the code developed for SMP didn't have to deal with this situation before.
Guessing even a bit more, this may be hard to fix in software. If the hardware simply doesn't protect registers properly, then the kernel may have to clobber them to protect the information, but that may impose far too much overhead for HT.
However, a workaround might be to permit HT only for multiple threads within the same process. That would still give some speedups to compute-intensive processes that are written to take advantage of threading.
Re:This ought to be interesting (Score:3, Insightful)
Re:This ought to be interesting (Score:2)
Re:This ought to be interesting (Score:5, Informative)
For instance, your web browser might spawn a thread to do a DNS lookup, since you wouldn't want the GUI to block during DNS. That thread hardly uses any CPU though. When your Web browser does real work, like rendering, it will usually be confined to a single thread.
Re:This ought to be interesting (Score:3, Insightful)
Quad-threading.
This way, the spy/trojan threads would not be able to presume anything about what else is being executed along with them unless they happened to be the only other running processes.
Of course, quad-threading on a P4 would be futile given that it has only a three-ways instruction decoder and integer execution units. If Intel replaced the AGUs by one extra complex ALU and two additional simple ALUs, quad-threading would become practical... though the six-ways instr
HT needs 1M L2 cache to avoid suckage (Score:3, Informative)
Back on topic: This attack doesn't real
Re:This ought to be interesting (Score:5, Informative)
Re:This ought to be interesting (Score:3, Interesting)
It sure sounds like this guy is on the up-and-up. When the full details are disclosed, I may (just maybe) forced to buy a new Intel system with HT -- imagine the possibilities!
Got some problem with pesky DRM? No problem! Run that nefarious application on the Intel HT box, and walk away with the keys. Sweet!
(Just need to make sure that that MSFT "Palladium" crap is turned off in the BIOS first, right?)
Re:This ought to be interesting (Score:5, Interesting)
I guess we will have to wait for his final paper which should be available in +12 hours or something like that.
Seems like he spent considerable time on this issue and he is unemployed. If you read his website, you probably come also to the conclusion that he sees this as an opportunity to get paid for his volunteer work. This
He could also have contacted AMD to get a little funding as they didn't jump on the HT train
opportunity to get paid for his volunteer work (Score:5, Insightful)
SCO Unix variants... (Score:5, Funny)
Re:This ought to be interesting (Score:4, Informative)
Re:This ought to be interesting (Score:2)
How so? Yet another broad sweep of the inference brush. What does HyperThreading have to do with dual cores? By your logic, all of the big SMP systems are also affected by this, which is simply not the case.
Whoosh!!! (Score:4, Funny)
Yeah, I think that was Intel's server market going right out the window at Mach 10...
Re:Whoosh!!! (Score:4, Insightful)
Re:Whoosh!!! (Score:2)
Re:Whoosh!!! (Score:5, Informative)
Re:Whoosh!!! (Score:2, Funny)
Re:Whoosh!!! (Score:2)
"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."
1. Most servers aren't multiuser (in the sense he's apparently talking about).
2. The workaround (of disabling HT) is trivial and won't have a significant impact for the majority of environment (proportionally very few servers are C
Quick fix (Score:5, Funny)
Think! (Score:4, Insightful)
Give us some more facts, so that we can think for ourselves.
Re:Think! (Score:2)
Re:Think! (Score:2)
Access to CPU/memory Calls (Score:2, Informative)
You need at least root/administrator privileges to get stuff from the OS memory.
So before you can exploit the system you must have access to the system it self.
It is an "local" kind of "root exploit" if you can read from the system memory of other processes if the claim is true.
Re:Think! (Score:2)
Then they put spider eggs in your bed.
Not many details (Score:2)
I do have to say it's commendable that he spent 3 months on this for free. Now that's commitment
Re:Not many details (Score:3, Interesting)
What Intel might hope for is that this is fixable in microcode. If not, well, then there's
Re:Not many details (Score:2)
Probably not. For example, under UNIX, the bug changes nothing for two threads within the same program, or for two threads under the same uids. On systems with messy and unnecessarily complex privilege systems (like Windows), all bets are off, however.
What Intel might hope for is that this is fixable in microcode. If not, well, then there's real trouble.
If people care about HT at all...
Re:Not many details (Score:2)
*sigh*
Re:Disregard Above Post (Score:2)
Eastern Daylight Time (UCT -4)
http://www.timeanddate.com/library/abbreviations/
Where's the details? (Score:4, Insightful)
Re:Where's the details? (Score:5, Funny)
Re:Where's the details? (Score:2, Flamebait)
However, we will see.
Re:Where's the details? (Score:3, Interesting)
Re:Where's the details? (Score:4, Informative)
The reason HT is vulnerable is because both threads share the cache and context switches can happen at any time. It could on normal non-HT procs too but the context swithces are more likely to flush the cache or not happen as often.
Re:Where's the details? (Score:4, Informative)
That would be the ideal solution (assuming that you also check for setuid/setgid programs). Unfortunately, it's really hard to do that correctly due to problems of kernel data locking.
FreeBSD's policy on security fixes is that they must never ever break anything -- so if necessary (as in this case) a simple but suboptimal fix will be used instead of a complicated fix which might have the inadvertent side-effect of causing machines to crash.
How to exploit (Score:4, Interesting)
Re:How to exploit (Score:5, Informative)
One final bit of information that should be included in a discussion of partitioned resources is the fact that when the Xeon is executing only one thread, all of its partitioned resources can be combined so that the single thread can use them for maximum performance. When the Xeon is operating in single-threaded mode, the dynamically partitioned queues stop enforcing any limits on the number of entries that can belong to one thread, and the statically partitioned queues stop enforcing their boundaries as well.
The same can be said for the register file, another crucial shared resource. The Xeon's 128 microarchitectural general purpose registers (GPRs) and 128 microarchitectural floating-point registers (FPRs) have no idea that the data they're holding belongs to more than one thread--it's all just data to them, and they, like the execution units, remain unchanged from previous iterations of the Xeon core.
For a simultaneously multithreaded processor, the cache coherency problems associated with SMP all but disappear. Both logical processors on an SMT system share the same caches as well as the data in those caches. So if a thread from logical processor 0 wants to read some data that's cached by logical processor 1, it can grab that data directly from the cache without having to snoop another cache located some distance away in order to ensure that it has the most current copy.
You might think since the Xeon's two logical processors share a single cache, this means that the cache size is effectively halved for each logical processor. If you thought this, though, you'd be wrong: it's both much better and much worse. Let me explain.
Each of the Xeon's caches--the trace cache, L1, L2, and L3--is SMT-unaware, and each treats all loads and stores the same regardless of which logical processor issued the request. So none of the caches know the difference between one logical processor and another, or between code from one thread or another.
more info at KernelTrap (Score:5, Informative)
Re:more info at KernelTrap (Score:2)
"The flaw affects all operating systems, and for a secure multi-user environment essentially requires that Hyper-Threading be disabled."
Seems that this is pretty big. Since I cannot see the direct link between multi-user and hyperthreading, I must assume that processes may be able to read data from other processes. Let's hope they cannot change the data as well. I think it's pretty weird that he mentions RSA specifically, maybe thats a hint which part of the processor
This is SERIOUS!!! (Score:4, Funny)
Ooooo, I'm SCARED!
hmm.. (Score:2, Funny)
Jason? Is that you? (or your evil geeky twin brother?)
Simple Solution (Score:4, Insightful)
Re:Simple Solution (Score:2)
Simplest Solution (Score:2, Informative)
Re: (Score:2)
Is this a hyperthreading problem or.. (Score:2)
if anyone has any more info on this i would be glad to hear it .
May I be first to say... (Score:3, Funny)
Bah... my ancient Sparc II scoffs at x86 (Score:2)
What is this x86 hyperthreading that you speak of fearing? My venerable (read:ancient) 64-bit Sparc II scoffs at your toy x86. Ofcourse, the aforementioned Sparc is only 1/2 the speed of your P3, but it stills scoffs.
[/humor]
Seriously, the SPARC architecture is an open specification that, unfortunately, does not get enough respect. It has been 64-bit since almost forever, something that is only now becoming common in the x86 world. I noticed that the flaws were noted on SCO-ware running on x86.
Reminds me of a bug in Michigan Terminal Service (Score:4, Interesting)
Extreme Edition... (Score:5, Funny)
With Moore's Law still holding up, isn't it a little early to be using up names like "Extreme Edition?" So, I'd like to propose my own corollary to Moore's Law:
"The microprocessor industry will run out of hyperbole long before they run out of transistors."
Re:Extreme Edition... (Score:3, Funny)
Google Adbar (Score:3, Funny)
I wonder how much revenue he'll get from this announcement?
And I note that if you are a SCO user, you always had disabled hyper threading anyway. Not sure what to make of that.
Re:Google Adbar (Score:3, Interesting)
I put adsense onto most pages on daemonology.net, just because I can't see any reason not to (given that the ads are reasonably inobtrusive).
This particular time, however, I had a very specific reason for putting them on: I wasn't sure if my server would be able to handle the load, and this way if there is too much traffic then I might be able to afford to get another server.
I wonder how
Oh dear. (Score:5, Funny)
Uhoh.. (Score:2)
Probably a Timing-Based Attack (Score:5, Interesting)
My guess is that this is a timing attack. While thread 1 generates an RSA key, thread 2 times itself performing various instructions. If thread 1 is using the FPU to do a multiply, the FPU won't be available for thread 2 right away, so there will be a measurable delay. Thread 2 can then determine when thread 1 is running multiplies.
If my hunch is correct, an OS could fix this by allowing a process to enter a "secure mode" which would force the other thread on the same CPU to be idle when that process was scheduled.
Re:Probably a Timing-Based Attack (Score:2)
Re:Probably a Timing-Based Attack (Score:2, Interesting)
Wouldn't that "secure mode" then become some sort of DoS attack? What if an arbitrary user process request repeatedly this mode, just as to slow the rest of the system to a crawl? I know there is now perfect solutions though...
Re:Probably a Timing-Based Attack (Score:3, Insightful)
Re:Probably a Timing-Based Attack (Score:4, Interesting)
Re:Probably a Timing-Based Attack (Score:5, Informative)
Other People's Cache - HyperAttacks with HyperThreading - Dag Arne Osvik, Norway
Absolutely... (Score:3, Informative)
In other news.. (Score:5, Funny)
stupid paranoid people (Score:2, Interesting)
Article in a nutshell (Score:2, Funny)
I'm not going to tell you how it works until I get a chance to stand up in front of a buch of people and sound smart. In the meantime you can disable HT.
I can write.
The flaw affects BSD's and OpenServer for sure.
I'm unemployed, so give me money to find more flaws.
Intel rocks!
Yup...that's pretty much it. Or did I miss something?
Same Guy? (Score:5, Interesting)
Re:Same Guy? (Score:3, Funny)
hohum (Score:2, Funny)
Too Scary ! Not ! (Score:2, Insightful)
Single Chip Multi Core (Score:2)
Is there a way to access registers on one core directly from another without a supervisor bit requirements?
Vector based systems I have been familair with use a sharded memory context exception handler for that sort of thing.
I think multicore CPU instruction sets are going to be interesting to look at as soon as I get my hands on one.
One more 4U chassis to add to the rack of equipment in my living room.
-hack
HT Explot PATCH:MST-00013 (Score:2, Funny)
You can download RIDDILIN.EXE to address the hyper-thread exploit from their update site...
Bill Gates assures me in a very personal email, installing this patch will fix the flaw, send me $5 for every other person who installs it... and Intel's stock will go up too. It's win-win...
Everyone should do it...
Timeline - WTH? (Score:2, Interesting)
Disclosure timeline
Re:Timeline - WTH? (Score:5, Informative)
They were. I've clarified the page somewhat now, but "Other security teams" includes Intel.
hooray ! (Score:2, Offtopic)
Security is a real-time embedded application (Score:5, Interesting)
For example, I know of one hack from the good old days that involved placing a password across a page boundary. The OS compared the password to a plain text version character-by-character, so faulted if the characters up to the page boundary were all correct. Observing the disk access light (or the time to reject the password) provided character-by-character cracking.
Of course, password checking is now more sophisticated, but so is cryptanalysis. I think people that use encryption for real are well aware that there's an exposure in doing so on any time-shared system, or any system that can be observed in any way by a potential cryptanalyst.
I would guess, based on the sparse information presented here, that this is the nature of the attack. If - and that's a big if - you can cause an adversary to be scheduled in just the right way, you may be able to capture part or all of a private key by observing timing artifacts of the hyperthreading implementation.
This may be good security research, but unless I were protecting state secrets, I'd wait and evaluate the risk relative to other security risks that we find acceptable. I would also guess that the exposure is minimal compared to other high-tech and low-tech potential information leaks.
Hyperthreading performance with numerical models (Score:3, Informative)
Here is a link which goes into detail [research.orf.cx]
Paper (Score:5, Informative)
Have fun reading, I'm going back to the conference.
Re:/. premature? (Score:3, Funny)
Re:SCO.... (Score:2)
cperciva told me he had contacted a lot of companies and OS distributions, but that there were only a few (four in this case) who replied to him about it.
Re:SCO.... (Score:5, Informative)
Actually, I posted to vendor-sec. I was rather surprised when I got an email back from SCO -- I didn't think that they'd be on vendor-sec.
You can't win for losing (Score:5, Insightful)
Yes. While I am a "full-disclosure is better than not" guy, you (or others like you) would be screaming even louder about how "irresponsible" this guy would be if he had released the "reason" today (said "reason," BTW is a proof-of-concept exploit, one that malicious jerks will probably adapt to their desires after it's released).
Oh yes sysadmins, disable hyperthreading because some poster on slashdot said so. This is just too gay.
Not as asinine as clueless AC posts like yours, modded up as "insightful" by equally clueless people who happen to have moderation points today. The guy is awaiting his doctorate at one of the world's most prestigious universities, has an excellent track record, and has chosen a conservative but less-controviersial approach in disclosing this issue.
All of which you would have known, if you'd bother to read TFA rather than spouting off nonsense here.
Re:So does anyone know... (Score:4, Informative)
Hyper Transport has nothing to do with Hyper Threading. Hyper Threading means processor support for several (usually two) execution threads at once. Hyper Transport is a bus technology to interconnect pocessors, RAM, motherboard chips, PCI bus and the like.
AMD's Hyper Transport is similar to Intel's Hyper Threading, but in my books, superior.
That's like saying that the computers from Apple Computers are similar but superior to the computers from Apple Records. Notice how Apple Records makes no computers? Just because they start with the same word does not mean two things are the same.
Re:2 or 3 months before notifying other vendors? (Score:5, Informative)
Two reasons. First, because I'm part of the FreeBSD Security team -- I'm required to notify them about potential issues.
Second, because if I contacted lots of security teams with what I had on December 31st, they wouldn't have listened: "Umm, hey guys, there's a problem with hyperthreading. I've convinced myself that it is real, but I don't really have any evidence to give you, so you'll just have to believe me..."
Re:Also announced by Adi Shamir in February (Score:3, Informative)
Yes, we seem to have discovered the problem independently. (Until today I wasn't sure if we had discovered the same problem -- Adi Shamir didn't reply to an email I sent him about this -- but I got an email from Eran Tromer after my paper went online.)
I don't want to pre-release their results, but