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.""
Then somebody else will.
A dictator who has made his domain open-source, thereby giving everybody free reign to change and make distinct copies of it?
Come on.
If Linus decides that he does not want to bump its priority up, someone else can fix it. Thats what fellow kernel developers do.
If Microtoft decides not to fix it, then no one else can.
so which one is a single dicatorship?
The answer to Linus' assertion that "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" is not to say "Well we all think its bad", but to produce a proof-of-concept exploit.
If he and "all the world's cryptographers" can't do that, then Linus' pragmatism beats the cryptographers paranoia (their defining quality, in my experience) into a cocked hat.
If an exploit can't actually be exploited, it's not and exploit.
you found an obscure and difficult to exploit vulnerability. Now quit trying to make out the world is doomed and trolling on Linus to keep the spotlight on youself.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
or, to put it in Pratchett's words:
He doesn't administer a reign of terror, just the occasional light shower.
If Linus is the dictator, does that make RMS the court jester? On second thought, do dictators even have jesters? This does not look good for RMS.
The all powerful Dvorak said linux had no leaders...
Hmmm witty sig or funny sig? Maybe elitest techy sig!
Now that I think of it I've never seen Castro and Linus in the same room....and Linus always seems to be smoking fine cigars...and open source software is practically communism anyway...it all makes sense now!
Everyone that disagrees with me is a paid shill
when Linus doesn't understand a problem, he won't fix it
This is interesting logic: The idea that the creator of an organization must understand minutiae and micro-manage everything that the organization does.
Interesting indeed...too bad it's fallacious. (Although it might explain what is taking Longhorn so long to come out - I can see Bill Gates searching Google for whitepapers on file systems, search algorithms, GUI's, etc.)
The kernel developers don't seem to agree on the right way to fix this, whether at the kernel level or in userspace. However, it may affect the performance of the kernel if it's done in kernelspace, and it is impractical to have everyone rewrite their userland software, as someone else pointed out. The "patch" which is available for FreeBSD to fix this problem only disables hyperthreading and does not provide a real fix.
"Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
All said cyrptographers should buy a non hyperthreaded cpu, or turn it off.
I mean if you use GPG on most machines, it will issue you a warning about Insecure Memory. That is someone could potentially harvest data from disused pages in memory.
These cryptographers would use a secure memory system. I'm happy hoping that MI6 isn't running a remote memory exploit on my box.
[% slash_sig_val.text %]
It's along the same lines of the "if all you got is a hammer" problem. If you've spent a lot of time working on something, it's obviously important to you. That doesn't mean that it's important to everyone else. This may well be a significant flaw from the crytographer's perspective, but then again, they study crypto a lot and have a vested interest in it.
As someone pointed out, yay for linux being free. As one or two above pointed out, someone who does care with the knowledge will write a patch. It'll get implemented as an option in the code, and if shown to be unobtrusive enough, may even get turned on by default.
-- Who is the bigger fool? The fool or the fool who follows him? --
The most common alternative model is community development, where a - usually but not always elected - committee of developer 'elders' steer the project. Apache and Mozilla would be good examples of the latter.
I appreciate some people have heard about this comment first today, people are joining the Free Software and Open Source communities all the time, but it kind of surprises me that so many are criticising Colin for this without anyone explaining this.
You are not alone. This is not normal. None of this is normal.
Scene: A wispy cloud scuds across the sunny blue sky. Not much happening, and the cloud is hardly even black.
Chicken Little: The sky is falling! The Sky is falling!
The Penguin DictatorNo, not really. It might fall, but it's very, very unlikely. So calm down!
Chicken Little: I strongly disagree. The sky is falling! And because you do not understand the problem we're all going to die!
The Penguin Dictator:Listen here. It's almost certainly not going to fall, and I need to worry about real problems!
Chicken Little: (Runs screaming to the nearest coffeehouse with free wireless, where he types incessently:) The sky is falling! The Sky is falling! Tell Slashdot! Tell Tom's Hardware! Tell Cnet! Tell Linux Business News!
The Penguin Dictator: Sigh. (And then he gets back to work. He looks up at the audience) They just do not get it, do they?
The Windows Dark Lord: (Rubs hands together) Excellent, MOST excellent. (Yelling) Bring me my marketing minion!
Marketing Minion: (being drug in by a bald guy yelling at him) Yes, O Master!?
The Windows Dark Lord:Tell all the peasants that the sky is raining huge chunks of fire and dung! Tell everyone, tell them now! And have our independent consultants work on this day and night, night and day! Make sure that they independently tell everyone that they can easily avoid falminf chunks of sky dung if they stand behind our Windows! And RAISE the price!
Some Guy At Some House In Some City Somewhere: "Wow, that was easy. Let me send this up to the Penguin Dictator. No sky ever fell, and that cloud is easily blown away. Nothing happening here, move along."
The Penguin Dictator "Well that was easy. Include this patch in the next day's weather update!" Marketing Minion: Press Release!!! Millions killed by falling flaming sky chunks of burning dung with brain eating worms who eat children!!! Run for your lives!!!!
Laura Didio, munching a do-nut"If you would hide behind Windows, the sky would stop falling! Your children would be safer and the world a better place." (looks at stoick ticker, says to self) 'Excellent. MOST excellent. Bring me a donut!'
The Penguin Dictator "Sigh. Why didn't I just keep Sky 0.7a for myself? Why the bother, wy the bother?"
EPILOGUE: No one was ever hurt by the piece of sky that never fell, and Chicken Little kept looking upward for another cloud to rant about.
The End.
Nice ad hominem attack. Attack the argument, not the person.
Not fixing this design mistake while laughing at respected experts in the field reminds me something. I was hoping that we as a community might have became a little bit more mature during the last decade, but I seem to have been naïve again.
I don't think Linus was "laughing at respected security experts" at all. For one thing this guy isn't a respected security expert - in my experience they usually have jobs. Secondly he wasn't laughing - his point was that the best way to fix the issue was to patch the userland crypto programs to be more immune to timing attacks e.g by making them read a set amount of cache lines each time. Anything that makes the crypto software more immune to these things seems good to me.
Also, how do you patch the kernel to stop this attack? The FreeBSD patch just disables hyperthreading.
I assume you can answer this since you sound like an expert. I also assume that you bothered to read the actual e-mails and not just the retarded Slashdot blurb.
But now I'm being naive aren't I?
... or in any other general-purpose operating system on a general-purpose computer. PCs are fundamentally insecure. There are a dozen ways to spy on cryptographic operations done in them, ranging from trojans, to hardware side-channel attacks, and dozens more to get copies of keys that they store. This is just one particular attack that may permit an attacker who can't get a trojan running with sufficient privileges to spy on operations directly to obtain some key bits. But if the attacker can't do that, there are lots of other ways to get the keys. General-purpose computers are simply not trustworthy.
If security is important, you do your crypto in a secure crypto module, like the FIPS 140-2 Level 4 IBM 4758 or the Level 3 Luna SA. Or, you use a general-purpose computer with special-purpose, very simple software and then provide strict physical access control to the machine and very limited network access -- often through a serial link using a custom protocol rather than via a real network. Or you could theoretically use a general-purpose machine with a TCPA chip with a regular, general-purpose operating system that has been modified to make use of the TCPA chip and with keys tightly bound to a well-defined system software configuration. But only if you have good physical security. In many situations it's still better to use a FIPS 140-2 Level 3 or Level 4 device.
IMO, the existence of weaknesses like this in Linux, and the fact that they're widely known, is a *good* thing, because it helps convince people not to trust that which is inherently untrustworthy. We need more publicity of similar problems in Windows (and there are lots of them).
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Why should this be fixed in the Kernel?
This appears to be an application bug, not a kernel one. The kernel never claims to completely isolate processes from one another; though there are memory protections, there are loads of ways that processes can observer each other's actions. This is just a particularly high-resolution one.
The real "bug" here, IMO, is that openSSL believes that no other process can observe anything about its secret computations. Timing attacks against RSA have been known for some time, particularly with regard to modular exponentiation.
It wouldn't be too hard to make RSA encryption take the same amount of time no matter what code path is used, and to make its memory access patterns uncorrelated with the keys (perhaps by using randomization during allocation). They should do this--the fact that their application leaks information has nothing to do with the processor it's running on; it's just that HT makes it particularly easy to measure that information. This would have a performance penalty, and I think the OpenBSD folks are too obsessed with performance, and that's why they've not done this. The performance obsession is a serious problem in the Unix world, and software systems in general.
If implementing openSSL effectively means adding special kernel support for things like constant-length timeslices or cache invalidation between context switches, that's fine. But this is not a bug in the kenel unless the kernel purports to enforce total separation between processes, which it certainly does not.
As to your last sentence, no the top poster doesn't explain it. The top poster simply describes the guy as an obsessive because he's put a lot of time into it, far more than a reasonable person might reasonably be considered to do. That's different from saying he's wrong.
My last paragraph was a comment about irony. It had nothing whatsoever to do with attacking your argument on the basis of who you are rather than your argument. It did, however, attack your argument. Your argument was that nothing this guy says should be taken seriously because of an accusation of being mentally off-the-wall. Nash is a perfectly good counter-example. The irony is that you unwittingly brought him up. There's no ad-hominem in there, I wasn't attacking you or your credibility, I was attacking your argument.I don't care if the guy's obsessive. I care if there's an exploitable vulnerability. Until someone writes code either way, the issue is unproven, but it's clear there's a potential, if unlikely (not impossible, just unlikely) to be useful, vulnerability there. Your comments and those of the thread originator are not convincing because they attack the proponent than explain why the argument itself is false.
You are not alone. This is not normal. None of this is normal.
He ran the bloddy "exploit" well over 1000 time to retrieve 30% of an RSA key.
Stop a mo and take a deep breath.
Take a look at your (heavily patched I'm sure) machine. If you had an unsupervised 24 hours with that box and an unprivileged account how many other actually useful exploits could you run for key retrieval.
I can think of about 5 methods right now that are much more likely to yield results within Linux. Even on a very up-to-date system with a decent admin.
Pfft.
- Storm in a teacup
No just compare every character in the input everytime, rather than short-cut when you know it wont match.
The normal solution is to store both the the real password and the password supplied by the user in a memory area that is as large as the maximum password length and zero padded and do something like this:
Note that it is also vital thet the password supplied by the user is zero padded and the calculation time can not depend on how long that password is. If it did, it opens up to man in the middle attacks. Evil, huh?
Try out fish, the friendly interactive shell.
He ran the bloddy "exploit" well over 1000 time to retrieve 30% of an RSA key.
Did you read a paper other than the one I read? I ran the exploit once, taking under one second, and I retrieved enough information to factor the RSA modulus N.
Tarsnap: Online backups for the truly paranoid
This issue exists with AES implementations as well (search for AES SBOX cache timing on google). The AES vulnerability is, if anything, more worrying in a way. It can be made to be constant-time, but at a serious cost in performance.
Here's another option: since this vulnerability depends on using the L1/L2 cache states to ferret out information, remove that from consideration. When processing an RSA (etc) key, have the code temporarily lock out context switches, AND have it take a fixed period of time to compute the result (or portion of the result), followed by flushing the cache. No data is left in the cache to analyze. The execution time of the code is fixed, so no dat leaks there. You don't have to make the algorithm a constant-time calculation if you can pad it at the end to the maximum (or close enough to the theoretical maximum that there's no true information leakage in practice). This helps avoid the potentially very slow algorithms that are truely constant-time. And flushing the cache at the end of each (portion of the) calculation removes that as a leak. (You need to flush it before waiting for the allocated time to elapse, note, and include max flush time in your calculation, and if possible factor into your calculation possible interrupt effects.)
A pain? yes. Requires extensive mods to crypto algorithm implementation? Yes (though perhaps not to the core calculation.) Requires OS support? Almost certainly. Requires HW support? Would be helpful but probably not required. Loss of performance? Yes, though far lower than disabling HT I imagine in normal cases (when not decrypting/encrypting).
Also, some of the restrictions above can probably be eased if the crypto algorithm is carefully designed and matched to the hardware.
Disclaimer: I am NOT a crypto geek! I have worked in processor and cache design, though.
I didn't know it was possible to time anything as (ostensibly) quick as strcmp.
strcmp may be fast, virtual memory is not. You just make sure that your password ends up split between two pages in the comparing program - for example by padding the previous thing you send over network with spaces. Then generate some activity to make sure most of the things are paged out. Now if the part of the password on the first page is correct, the program will take longer to return failure and an extra page should be visible through vmstat. By repeating this with different alignment, someone can guess your password character-by-character.
I am afraid multi-user systems are there to keep students from stealing each other's homework, not for protecting military secrets. Over the Internet, such small variations in timing should be impossible to measure. You can insert a random delay every time your program processes an incorrect password for good measure.
I wonder why Colin didnt' spend his 3 months of unemployment making a user space fix for this issue...
Two reasons: First, I was busy informing vendors -- Intel, Microsoft, the *BSDs, and Linux vendors -- about the problem and explaining the possible solutions. Second, because fixing every application in the world (this doesn't only affect cryptography) would take far more than 3 months.
Tarsnap: Online backups for the truly paranoid
First, remember that public key exchange is usually a very small component of a cryptographic session. Usually, you do all the public key work at startup, exchange private keys for the session, and then just use the private keys. So an inefficient solution that protects the public key computations is acceptable.
In the paper, Percival writes "Further, OpenSSL utilizes a "sliding window" method of modular exponentiation, decomposing x := (a^d)
mod p into a series
of squarings x := x^2 mod p and multiplications x := x ^ (a*2*k+1) mod p." When there's a zero bit in d, the squaring and multiplication are unnecessary, and the SSL implementation apparently skips them. That creates the covert channel. It should be sufficient to revise the code so that it always does the squaring and the multiplication, and then uses the zero bit in D to decide whether or not to use the result. Because some superscalar CPUs might manage to look ahead and avoid the squaring and computation, a nice solution would be to compute both x := (a^d)
mod p and x := (a^(d XOR K) mod p, where K is all binary ones out to the maximum length of d. This makes the computation symmetrical, independent of the value of d. This should roughly double the cost of the public key computation, which is probably tolerable.
It's now important to also examine private key mechanisms for similar vulnerabilities. In particular, DES implementations should be checked. Because those execute millions of times during a long data transfer, even if there's a low-bandwidth leak, an exploit may be possible. Some lookup-table based implementations of DES might have exploitable cache semantics, and that needs to be explored.
Potential performance problems are things you should defer on until proper profiling can be done (unless they're total show stoppers). Security and correctness are things you cannot ignore except in extreme cases. Security is particularly important to nail down, because it can result in your customers losing data (even data not pertaining to your app), which is the first no-no of software.
Application software has four priorities, in this order:
- Safety (shouldn't destroy data)
- Correctness (do what it says it does)
- Security (don't do anything else)
- Performance (do it fast)
YMMV, of course, sometimes correctness falls below security, and occasionally performance goes above correctness in some mathmatical functions (if doing it correctly would take a decade and doing a close approximation would take a day, obviously you want the approximation and then a heuristic). In this case, I'd say proper fix is to disable hyperthreading by default, and make sure the user is aware of the hardware bug/consequence of using HT when they decide to turn it on. You need to let the user decide if they're willing to accept the security risk or not.The Linux Kernel Developers may decide otherwise, but that's how I'd call it if it was in my shop. It's a hardware problem and the software fix is not obvious.
Slashdot. It's Not For Common Sense