Slashdot Mirror
Hyper-Threading, Linus Torvalds vs. Colin Percival
OutsideIn writes "The recent Hyper-Threading vulnerability
announcement has generated a fair amount of discussion since it was released. KernelTrap
has an interesting article quoting Linux creator Linus Torvalds who recently compared the vulnerability to similar issues with early SMP
and direct-mapped caches suggesting, "it doesn't seem all that worrying in real life." Colin Percival,
who published a recent paper on the vulnerability,
strongly disagreed with Linus' assessment saying, "it is at
times like this that Linux really suffers from having a single dictator in charge; when Linus doesn't understand a problem,
he won't fix it, even if all the cryptographers in the world are standing against him.""
Actually, my bet is it will be fixed in the new CPU revision, by Intel. And eventually Kernel fix dug into the config somewhere next to other "bugfix/support" entries, with note like "Early multithreading Intel Pentium 4 CPUs have a vulnerablity that allows to override privledges of a process. This entry includes a patch for this bug at cost of increasing the kernel size by 32K and slightly slowing it down. If you have an early Pentium 4 processor and run a multi-user system, say Y. If you don't or aren't sure, say N."
Anagram("United States of America") == "Dine out, taste a Mac, fries"
Why wouldn't he?
He doesn't say "I don't want a fix for this anywhere in the kernel" anywhere. Just that he doesn't think it's a very critical issue.
If someone else does the patch for him, why wouldn't he accept it?
Beware: In C++, your friends can see your privates!
RMS is more like the tribal elder reminding you of your ideals - especially during those times when you consider putting them aside because they seem impossible to live up to.
I'm not to sure about that. Linus says this is a library issue and I agree. The kernel should not try to fix library bugs.
What this bug amounts to is this: When a program is performing calculations using secret data like an RSA key, it is important that the data access patterns do not depend on the secret data, since these patterns can be analyzed by an attacker.
An example of a classical vulnerability of this sort is using the c function strcmp to compare the real and the supplied password. By timing multiple runs you can get a decent estimate of how long time the strcmp function took, which means you can guess which character was first differing character in the password.
The security flaw in HT is that a process running on a HT CPU can get quite a lot of information about the data access patterns of the process on the other virtual CPU on the same chip. In other words, the severity of any library bugs which cause different access patterns on different secret data has been severly increased.
Try out fish, the friendly interactive shell.
No just compare every character in the input everytime, rather than short-cut when you know it wont match.
That sounds like it has some non-trivial costs associated with it. That would mean losing performance in many instances where two high-cpu processes want to be exectured on a single physical processor at the same time.
The best solution is to just fix the crypto libraries as a short term solution, and for Intel to fix the chip in future iterations as a long term solution. Mucking about in the kernel and having other unknown effects seems like a bad approach when the problem can be fixed elsewhere.
AccountKiller
I dunno if I agree, for two reasons. First, you'd be surprised what a sophisticated, determined and deep pocketed adversary can do (e.g., the smart card vulnerabilities that were uncovered a few years ago by analyzing the power consumption).
Secondly, just because the clock is ticking fast doesn't mean you can't count them as they go by. The same process run at 1Mhz and 1Ghz is going to look substantially the same, because you're monitoring them faster too. If anything, you're less likely to get interrupted by I/O during the process.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Faster processors also means that you don't need to be as precise. You can search more possibilities faster, but every byte you can chip away helps narrow down the search range.
It's true that there are various "noisy" and uncontrollable aspects of modern CPUs, but if you take enough measurements and can establish a control, you can get valid information. It will not give you "the answer", it may help you to eliminate a set of data that is "not the answer". That is extremely valuable.
Some people actually monitor chip power supply variations to try to get this information. I won't pretend to understand how they get meaningful data from this, but it involves knowing the system under attack very well, and wanting the data really, really badly. Hence very high security systems shield their processors magnetically and inject "noisy" (bogus, unrelated) operations to cover this. It sounds like a pipe dream, but I've visited places where these systems are built (think Blue), and read some of the papers describing these exploits.
His point is valid, ANY information an attacker can get significantly reduces the integrity of the encryption. I just suspect Linus' point is that most (I said most, don't flame me) linux server deployments are geared towards not letting people on the server in the first place. This vulnerability seems to be valuable mostly to people who already have access to the system.