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.
Well Played
Dictator? Yeah, right.
A dictator who has made his domain open-source, thereby giving everybody free reign to change and make distinct copies of it?
Come on.
Linux really suffers from having a single dictator in charge
Critical to the Open Source model is agility, and it's why Windows is at a strong disadvantage to Linux -- they can't have the same agility as we do.
There isn't a single dictator in charge of Linux, only a media figurehead. Try telling that to the media, who can't yet comprehend our multidimensional, fractal, Open, Source, methodology.
The dangers of knowledge trigger emotional distress in human beings.
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 solution just presented itself! Multiple dictators for everyone! Oh what fun!
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
Colin needs to cool down a bit. At least the Linux distros (SuSE, Red Hat, etc are the ones which will get a problem from affected systems) are going to get patches for it. From Linus or any other Kernel developer.
Linux is Open Source. So it does not matter what the dictator thinks. Because even if he is, like Colin childishly claims, a dictator, he does not have any real power over Linux users. There are, in fact, dozens of flavors of Linux kernels available on the market. And almost none of the major distributions today use the stock vanilla kernel, most of them ship with kernels who include numerous patches who are not part of the vanilla kernel. If Linus does not make a patch, someone else will. And chances are high the patches will be taken into the vanilla kernel. But even if such patches are not accepted into the vanilla kernel tree, they can still be applied to it. This is why Open Source wins. We have the source, the source is with us - And we are free to do what ever we like with it. I can apply a secure patch if one comes available regardless of what the dictator thinks of that, and that is obviously why it is totally wrong to call a person who is kind enough to use hours and hours of his time to develop something that greatly benefits mankind a dictator.
9/11: Never forget it was a false-flag operation
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!
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.)
From the original article
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
First the Bitkeeper Tridgell accusations, and now this comments with a flavor of "no, it can not be better"... I guess Mr. Trovalds is entering the age where the ideas and innovation are not emerging, sad for this but, I guess we will start to see these kind of comments and actions from the Linux founder...
Ubuntu is an African word meaning 'I can't configure Debian'
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 %]
I was getting a buzz from all those buzz words....
I'd like to address this directly because I find it funny that AC would suggest open source was anything but a multidimensional methodology. Clearly you have no understanding of the subject matter, buzz words or not.
The dangers of knowledge trigger emotional distress in human beings.
By being able to reasonably guess what another program is doing, you can design attacks around it. You dont have to target stuff as specific as crypto keys.
Stuff like timing attacks. A timing attack that might have been difficult or impossible before, may be possible or trivial now.
No crypto involved.
Linus doesnt actually sit there writing the entire kernel. It is impossible to have a "dictator" in an open source program. If Linus doesnt get it, someone else who gets it can fix it and it will be fixed.
-- 'The' Lord and Master Bitman On High, Master Of All
Yes Linus decides what goes in the vanilla Linux tree, but how many distros use that? they all patch their kernels with enhancements.
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? --
Now that I know Linus wrote all of it and fixes all of it I'm well impressed!
The solution for this is just like the "Java should be open source" argument that people always float. "If Java were open source, we could do a fork and fix what's wrong with it".
If you don't like what's going on with the project, do a fork of it, and fix it.
At least, that's how the argument goes when people are talking about Java. Since this is the Linux kernel, people seem to be a bit unwilling to do the same thing.
It's long since time that there be splits in the kernel. This whole thing with SMP is going to turn around and bite Linux if something isn't done about it soon. Other operating systems are prepared (or are preparing), why should Linux be so far behind?
And don't make the argument that Linux isn't really that far behind. It is. If Linus had started the work several years ago, it wouldn't be as big of a problem. The trouble is Linus doesn't want it mucking up the kernel, or making it harder for other people to code for it.
Well, doing the work to get multiple processes in kernel context (not just two or three, I mean a LOT of processes) IS hard, and it will be difficult for people to program under the new kernel rules.
It doesn't mean the results aren't worth it though.
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.
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.
Having only one point of fracture, only one right or wrong director of orchestra its not as bad as sound. Both music orchestra and army use a system where one leader and others follow. This help as you receive only one voice and clear. Even if that guidance fail, the "commander" can change the route. So its not that bad, Its work for some human areas.
-Woof woof woof!
"it doesn't seem all that worrying in real life."
Yeah, just like a mouse driver having full access to kernel security structures and raw disk partitions, it doesn't seem all that worrying at all (except when your entire system crashes thanks to a buggy sound driver, or you get rooted, or...).
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.
Karma: Positive (probably because of superiour intellect)
Colin Percival, who published a recent paper on the vulnerability,
Well, it's obvious that he has to be right then, since he has published a paper on the topic, right ? Right ? Nobody else can "understand a problem", only him, since he's got a paper on it. A real paper.
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
"even if all the cryptographers in the world are standing against him"
Who would understand what they are saying anyway?
From this it should follow that we listen to them, not that we dismiss what they say!
I'm glad that the construction engineers who design the bridges we ride over "study [bridges] a lot", and aviation engineers who designed the plane I am about to ride on "study [planes] a lot" and you bet they "have a vested interest" in safety.
Praise the experts who "study a lot", for without them, we'd all be dead. :-)
you had me at #!
Linus seems to be intelligent enough to understand when to undertake certain tasks. Up to now, no one knew about the vulnerability. There hasn't been solid proof of exploit released in virus form yet. All this is, as of yet, is FUD. Linus doesn't want to reshape his priorities because of newfound FUD, and he's very smart in doing this.
I'm sure that if an exploit is found, someone will have a patch ready for the next kernel revision - that's the beauty and advantage of Linux.
Colin Dean Go a year without DRM
If you've got hackers coding exploits and targetting threads on your machine... perhaps Hyperthreading isn't your biggest problem.
[% slash_sig_val.text %]
oh! I can't use this hammer because other people like it too much!!
They tell me how great it is and they really like it, so I can not use it!
I might have my facts wrong but having a dictator can sometimes get useful things done when a voting board cannot. (Xfree)
And then even with a board people bitch about them too.
So how bout we just have a source tree where everyone and anyone can write to the tree and see where it takes us?
Actually that could be fun. Make it so.
-- taking over the world, we are.
How silly to make an OS decision based on those two reasons you wrote....use the right tool for the job, or you'll be (duh!) using the wrong tool. Mine are FreeBSD for 'net gateway, Linux for general-purpose work & Windows for gaming - I pay no attention to coolness factor (or the revese-snobbery counterpart) and go on technical strengths...
... 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.
A dictator who has made his domain open-source, thereby giving everybody free reign to change and make distinct copies of it?
Ladies and gentlemen, let me introduce Linus Benedict Torvalds, The Bizarre Dicatator of Bazaar, who can command anything to anyone (and no one has to listen). Bow before Him!
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."
This reminds me of when, mid stable branch, the VM system was changed in Linux.
It also reminds me of when Linus said something to the effect of, "I have not looked at BSD lately or Windows XP, but I don't see anything worthy in them".
Dictatorships are great if the dictator is very wise and well intentioned. I am glad that OpenBSD has a dictator like Theo de Raadt.
War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?
... is just trying really hard to get his few moments in the limelight.
A working exploit would change the priorities, but there aren't a slew of people who even can understand the complexities of programming a system to exploit this bug under most *nix os.
Shadus
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.
"Extrordinary claims require extrordinary evidence"
My read is that Linus thinks that it might be a problem, but isn't convinced of the real-world seriousness of the problem - yet.
If you're going to claim that the sky is falling, you'd better bring evidence - like a reproduceable exploit. If you have one of those, you'll get the attention the problem deserves. And if you can't... then a problem that isn't a problem isn't a problem, isn't it?
DG
Want to learn about race cars? Read my Book
"even if all the cryptographers in the world are standing against him."
Linus: No just you Colin!
why whine about it? 'wah wah theres a bug and he wont fix it booo hoo'
people that are whining about it know how to fix it, send the man a patch, and be done with it!
all talk and no action. perhaps he doesnt know how to fix it, and you do.
DO IT! STOP WHINING!
However in this case, the evil dictator is correct, this isn't a kernel issue.
Damn, that's subtle. I mean, I can figure out how it would work, but still. I didn't know it was possible to time anything as (ostensibly) quick as strcmp.
So, what's the solution? Adding a random delay to the loop?
--grendel drago
Laws do not persuade just because they threaten. --Seneca
There was a paper on this type of covert channel and on possible countermeasures at the 1991 IEEE Symposium on Security and Privacy.
Hu, W.-M. Reducing Timing Channels with Fuzzy Time. in Proceedings of the 1991 IEEE Symposium on Research in Security and Privacy. 20-22 May 1991, Oakland, CA: IEEE Computer Society. p. 8-20.
Is this the same Colin Percival who ran the Pihex project a while back?
Clever boy.
Can anyone interest Linus is sharks with lasers on their heads? Real estate inside a volcano, perhaps?
Someone's emotional state is affected by this sort of thing. You can't say it isn't so.
Several years ago I came across a little project by Colin Percival to calculate Pi to an obscene number of digits called PiHex. I thought it was pretty cool and I think this guy is damn bright. I expect to hear more about him in the future. A lot of people here seem to be dogging him because he has been critical of Linus, but I think what he wrote was fair. At least everything I saw. It isn't like he was saying Linus sucks or anything, just that he isn't taking a threat as seriously as Colin would like him to. Hey, part of open source is collaboration and that sometimes means people are not going to agree.
Links for the PiHex project:
http://www.cecm.sfu.ca/projects/pihex/index.html
http://www.cecm.sfu.ca/projects/pihex/colin.html
Why are all the cryptographers standing against him when they should be helping to educate him on the seriousness of the problem (if it truly is that serious)? Instead of being juvenile and throwing stupid statements to the press, why don't they start a dialogue to resolve the problem! Acting like a bunch of teenagers in public is NOT going to solve the problem.
An earlier article on Slashdot mentioned that Hyper-Threading, as currently implemented on Intel Pentium Extreme Edition, Pentium 4, Mobile Pentium 4, and Xeon processors, suffers from a serious security flaw. Since the security flaw is in the processor then isn't this also a Windows issue? If not, why not? If so, what do the folks at Microsoft think of the issue? Are they reacting to it more like Colin or Linus? How Microsoft's treatment of this issue could provide some meaningful perspective here.
Making the world a better place, one psychotic episode at a time.
There is a big differance between saying "The vulnerability isn't really that bad" and saying "I'm never going to fix it". Linus is probably right to some degree about the severity of this attack vector. That doesn't mean that he won't fix it, or someone else will be allowed to.
Everyone is so excitable these days.
to secure boxes.
If you're really worried about exposing some of your user space to 'malicious multi-threading' (which depends on a lot of factors to yield any possibility of capturing useful data,) perhaps you should not be running you code on such a compromised architecture as the x86.
I think a caveat, don't trust this box to do crypto, and a recommendation, turn off hyper-threading, is enough.
In fact, whatever software requires it turned off should be able to find out from the machines geshtalt and possibly issue a request to turn HT off while its running.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
Why not disable hyper threading if this is an issue for your servers security? You won't lose *that* much performance.
I generally found it can have an adverse effect on our servers performance anyway.
If a process is leaking information somewhere, then there will be people clever enough to pull that information out.
That said, it seems that this is more of a library problem than a Linux problem.
If you need any real security you should be doing your private-key operations in an HSM anyhow, not on your CPU.
Lasers Controlled Games!
Just like Linus vrs Tridge, except in this case Linus hasn't said ANYTHING in this exchange that indicates he won't accept such a patch.
Percival is just blowing smoke up everyone's ass. His only point is that the NSA is concerned about a covert channel - fair enough. Linus is doubting it's a practical method of doing this, and he also doubts that for ordinary users (other than the NSA) it's possible at all to use it for a covert channel.
Even if proven otherwise, it says NOTHING about whether a patch would be accepted by Linus.
This is total bullshit UNTIL Linus refuses such a patch AND his reasons for doing so AT THE TIME HE DOES IT are proven wrong.
And even then, as others have said, any distro can add that patch for people who care such as the NSA.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
Just use a kernel without SMP capablity in Linux and voila - no vulnerability.
This isn't a kernel problem.
It's either an application problem or a hardware problem. Basically, used memory is not being zeroed out, so one programme can look at what another programme left behind.
In the case of a software frame buffer {like the 1980s home computers with bit-mapped graphics: Spectrum, BBC et al} failure to zero out memory causes spurious artifacts on the display. You can see this if you switch between graphics modes by writing to the hardware registers directly rather than using the "proper" system calls which clear the screen. {On the Beeb, you could actually grow a stack through the display memory. Pretty, but you'd better hope not to scroll the screen or print over that area.} The solution was implemented in software: create system calls that zero-out the display memory when switching graphics modes. {As a bonus, your users need only send one number to the routine, which can poke the right values into all the relevant registers on their behalf. They just don't get to invent their own graphics modes, but if you ever update the display ULA in future then at least you won't kill half the games software in existence.}
What we're talking about here is cache memory not being zeroed out between uses by successive processes. That looks to me very much like a hardware problem. It's not even an easy problem. My guess is that the implementors looked at it, decided "It's potentially insecure in theory but bloody difficult to make use of in practice", and left it that way on purpose. Like there's no point fitting an expensive lock on a wooden door with a person-sized glass panel in the middle of it -- especially if that door is only accessible through an overgrown garden with an underfed Alsatian in it.
BTW, crypto software running in userland could never, ever be made immune to snooping from kernel space -- at least, not on a system with any kind of debugging. The solution is to read and understand every bit of the kernel source -- including all drivers -- or get some independent expert to do so for you, so as to be sure the kernel contains nothing that could be used for malicious purposes. Hardware crypto devices would be more immune to tampering -- but less susceptible to independent verification.
Imagine this: <CHEESY MEXICAN ACCENT>Hey, extranjero! You want to send secret message? I chave code so secret, nobody onderstand eet 'cep' for me an' my brother. Djou dictates to me, one word a time, I write eet down in secret code. Then I send eet to my brother and che go to your amigo, and read heem the secret code. Nobody in world onderstand 'cep' my brother.</CHEESY MEXICAN ACCENT>
Je fume. Tu fumes. Nous fûmes!
Hey just has people's trust. Anyone (and everyone) could take the source and start their own thing. If EVERYONE really was aligned against him this is what would happen.
Folks trust him because he's a bit pragmatic, and doesn't troll to high heaven. Looking over the background their are other fast channels, I'm not sure I by the 1000x faster arguement given sched_yield() etc. So yeah, something good to fix, but let's stop with the linux as dictator. He's only dictator as long as the people who matter are willing to follow him.
Linus A Dictator ?!? LOL!! The Kernel is open source , Linus feels that this Bug isn't such a big problem,something he is entitled to do.But anyone who Disagrees can go ahead and write a patch/fix, that means Vendors too.Does Colin know why this can be done? Because Linux is open source. So much for Dictatorship HuH? Next he'll be calling Linus a communist. Go Figure....
If Red Hat or SuSE or anyone else disagree with Linux, they can simply produce and apply a patch to their own kernels while releasing the patch itself to the public.
This is one of the good aspects of open-source software: If you disagree, you can fork or simply distribute a patched product.
Stop the brainwash
Or even better, use Hyperthreading against itself to solve the problem-- start another thread that randomly peeks at the table.
Now was that that hard to figure out?
I wouldn't trust a machine that had people logged into it that were untrusted. Real vulnerabilities that allow untrusted users to install trojan binaries is a much more real and dangerous security problem.
This is certainly an interesting problem, but it's not that high up on my list of priorities. And I'm not surprised that Linus doesn't feel it's a terribly important issue, especially since the particular example given in the paper can be fixed by modifying the openssl library. (thus fixing the problem on Linux, FreeBSD, and any one else who supports Hyper-Threading Intels).
“Common sense is not so common.” — Voltaire
*Takes out popcorn*
*Observes all Linux fanatics defending their precious operating systems/kernels*
Really, when someone says something "bad" about Linux or its creators it doens't mean they're all out to get you, destroy you, etc etc. I'm sure all fancy dangled open source projects and fun and stuff (even though I'm currently not involved in one) but I still am not able to understand why everyone goes berzerk when camp A says something about camp B.
Same goes for Mac & Microsoft zealots.
Proud owner of BOT2K3 [ bot2k3.net ]
did you guys consider that Colin is maybe right and Linus isn't? After all Colin researched the topic for three months, while Linus (and the rest of us) have thought about it for a few hours at best.
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.
It seems all geeks can do these days is rant about esoteric security flaws and patch them as if every guy running Firefox had pentagon launch codes on his linux box. Let's just admit one thing: for every known security flaw, there are dozens that aren't, and probably a few that are by the wrong people. We continue as a viable species despite this fact not because of our ability to ensure perfect mathmatical security, but because most people really aren't evil. Maybe we should spend one day a week actually using computers and leave the rest of them to obsessing about security.
Wouldn't the open source nature of Linux, however, be exactly what prevents Linus's stubbornness from completely ruining it? If he doesn't make an "official" approval of a fix to this security issue, someone else can make a patch for it and release it, rendering Linus's kneejerk opinion rather unable to do harm.
And if such a patch is downloaded and eventually used by the majority of, or at least a significantly sizeable number of, Linux users, Linus will no longer be able to ignore the demand for it.
Posted as AC because some Linus Torvalds groupies will reactively mark this as flamebait without even reading it.
Now it make sense!
http://www.theinquirer.net/?article=23300
Pussy, pussy, pussy! All pussy must go. At the Titty Twister we're slashing pussy in half! This is a pussy blow out! Make us an offer on our vast selection of pussy! We got white pussy, black pussy, Spanish pussy, yellow pussy, hot pussy, cold pussy, wet pussy, tight pussy, big pussy, bloody pussy, fat pussy, hairy pussy, smelly pussy, velvet pussy, silk pussy, Naugahyde pussy, snappin' pussy, horse pussy, dog pussy, mule pussy, fake pussy! If we don't have it, you don't want it!
Linus probably would do something about this if all the cryptographers in the whole world said it mattered. But, so far, Percival is the only person who seems to think it's actually a problem. Nothing on the subject from Bruce Schneier. And, while he says Linus should talk to the SELinux people, he probably doesn't realize that they have almost certainly heard about this and didn't comment in the thread.
It wouldn't be hard to have an option to prevent processes with different owners from running on the same physical CPU at the same time. It wouldn't even affect the case that Linus mentioned. But cryptographers don't seem to think it's a plausible attack anyway, aside from carefully arranged conditions. The discussion was entirely over whether it would be less foolish to prevent it in the kernel or in userspace, and nobody seems to have argued that anything should be done at all.
My point would be that I think folks *often* make the wrong decisions because of how "cool" linux is or because they hate MS, like the guy who tries to get his parents to use linux when all they want to do is check their mail. Often when talking to linux "consultants" and I say I need to do "X", which can be done easily in another OS, they will try to change X rather than admit that linux can't do it.
But of course, I should have realized that speaking out against linux and/or Linus on here would get me modded down as a troll...
"Where quality is like a dead stinking rat - you just can't miss it."
Certainly, this covert channel is possable in theory, but is extremely unlikely in preactice. It looks like a few pre-conditions are necessary:
The blackhat program MUST be running on the same CPU as the program it wants to snoop AND it has to know that. There must be just enough processes runnable that it does run on the other virtual, and no more (or other processes will perterb the cache).
It has to just happen to not have an interrupt perterb the cache. Good luck on that one. Better luck KNOWING that for sure without screwing the cache up yourself.
It also must have at least min imal cooperation from the snooped process. For example, the snooped process can really screw things up by occasionally bypassing the cache (there are asm instructions for that). Sufficiently worried cryptographers can do that if they like.
Sufficiently worried sysadmins can disable HT in the BIOS.
Sufficiently worried kernel programmers can modify the scheduler in several ways, such as reserving HT virtual processors for processes with more threads than available CPUs.
SELinux can hack the scheduler to olny allow the virtual CPU to be used by another process/thread in the same domain and sensitivity level. Of course, they are probably more interested in dealing with things like X cut/paste etc.
Nearly everyone else can just ignore it as one more thing that could be a problem in theory, but is quite unlikely to work in practice.
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
So, the troops begin to turn.....Soon it will be:
Emporer Gates
Darth Linus
Steve Jabba
Who will we have to ridicule for being successful when we can no longer rally around Linus as our champion against the Empire?
This is another reason to switch to AMD. Faster and more secure.
Single server running virtual server A & B.
Virtual server A is a bonafide E-commerce site w/ users submitting transactions via SSL.
Virtual server B looks bonafide but it instead of logic to serve pages, it continually calls a HT snooper program. The key here is you do not need priviledged OS access because as long as your website code is scheduled to run, it can snoop info from parallel HT threads.
Compare: making all users run as root to speed up login times.
"I assumed blithely that there were no elves out there in the darkness"
Why is it that so many people are claiming that there is no way to fix the bug, or that fixing it would destroy overall performance? The solution is both trivial and obvious. In fact, it is right in the name: HyperThreading!
The problem is that two separate processes running on the same processor have too much access to each other. Simply use the feature as it was originally designed and intended: only run threads of the same process on a HyperThreaded processor. Problem solved. No extra overhead for other processes, keep the benefit of HyperThreading, and it will even eliminate the pre-2.6 scheduler problem that caused HyperThreading to reduce performance. Has no one at all thought to look at the name Intel gave the feature in the first place?
This is not intended in any way as a troll (merely informative to other readers who may not have come across him yet and wonder what we are talking about), but I take it from the UID you do this with the full knowledge that Theo is, on all apparent evidence, a bit of a nutter, a bullshitter (with reference to his utter bollocks about 'Linuxes'), and that rather than OpenBSD being founded out of some earnest devotion to security of his[1], it was because his access to the NetBSD CVS repository was pulled, on the grounds that he was being a class jerk to both users and other developers (not a exactly an isolated incident).
;-)
:)
[1] In fact, he originally intended it to be called NextBSD, because he seemed he was basically intent on running his own show all along (which seems to me to be due to him 'not playing well with others').
While the development of OpenSSH remains a much valued contribution, from a security standpoint OpenBSD really has a long way to go to catch up to Linux as far as meaningful features go (the security hype being primarily based on (a) the contribution of OpenSSH - which Theo said he didn't want to make for any OS other than OpenBSD! - and (b) simply having all the services turned off on a default installation).
Specifically (and unlike Linux) OpenBSD doesn't support MAC (Mandatory Access Control) restriction on files, nor does it allow the restriction of access to raw devices, memory or sockets for any user (including processes executed as root), hell it doesn't even have ACL's (Access Control Lists) support without a 3rd party patch (e.g. with patches based on FreeBSD 5's implementation), and they don't seem to 'get' why anyone would want it. In fact, they have *actively* decided not to even attempt to implement POSIX.1e (according to this book, endorsed by Theo).
These are features that have been supported by Linux for years. If (and I honestly think it's going to be 'if' rather than 'when' now), OpenBSD begins work to implement these features, then it might start to be considered useful as a secure platform. Until then, it's very lacking in meaningful features indeed. In fact, other BSD variants are already ahead of OpenBSD in so far as implementing them (such as FreeBSD and TrustedBSD).
I realise it's considered easier to criticise than give due credit by some, but in the case of Theo De Ratt I can't see that the amount of credit he gets from some quarters is warranted.
In conclusion, this is why I find the inference that he is 'very wise and well intentioned' at best riotously amusing.
( YMMV.
Random delays are bad.
Random delays can be averaged out.
The best option is to make it take *constant* time for both success and failure.
The constant betrays no information, thus you will remove the information instead of making it less accurate or otherwise obfuscating it.
I believe that this same principle holds for pretty much all timing attacks.
> "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.""
An OS dictator over 10 million times the size of Linus has been brought to its knees over lax security.
If Linus' fantasy about mass use of his OS ever remotely comes about, the assault of 30,000 raptors and 2 million scavengers slicing at it continuously will change his tune.
What was that about "You can fool all of the hackers some of the time, and some of the hackers all of the time, but you can't fool 30,000 hackers all of the time...when they turn around, look up, and focus their attention on your OS."
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
How bout have threads be associated with a bit like NOT_OK_FOR_FOREIGN_PROCESS_HT. Most threads, having no such securtity concerns, would have the bit off and the kernel would schedule them as normal. Threads for crypto would set the bit on and then the kernel would only schedule those threads to run with threads of the same process on the same physical processor at the same time.
The Ravenous Bugblatter Beast of Traal approach to security:
The Ravenous Bugblatter Beast is so mind-bogglingly stupid that it thinks that if you can't see it, it can't see you. Therefore, the best defense against a Bugblatter Beast is to wrap a towel around your head. - Hitchhiker's Guide to the Galaxy, Douglas Adams
Microsoft used to have the same attitude about dictionary attacks on passwords until l0phtcrack came out. But the underlying issue was proven long before l0phtcrack came out.
Moreover, this general class of attacks was proven about 10 years ago and several times since then. Proven in theory and demonstrated with code.
I'm glad that when cryptographers say "you should encrypt the swap space, otherwise people who steal the machine might find cleartext passwords in it!!", Linus says "that's retarded, it's not going in main".
"...he won't fix it, even if all the cryptographers in the world are standing against him."
...
I'm sitting down you idiot! What about all the cryptographers
in the world who happen to be sitting down at the time?
What about all the cryptographers who are taking a shower
not that you ever take a shower not withstanding.
Piss off fagget! What's the problem? Haven't had dick to suck
today?
I don't expect you to understand English you insentitive clod.
Toodles
There's value in user identification, it makes it possible to have different files and settings for different users. There's no intrinsic value in disabling HyperThreading (except in cases where it actually increases performance, but I think that's very rare in practice). But giving root access to every account is a problem we haven't been able to solve. There are various half-assed attempts, like sudo and groups in Unix, or Power User status in WinXP, but frankly they suck, we put up with crap like that only 'cos we don't have anything better (or, as most people with Windows, just run everything as administrator).
Of course human nature may make this an unsolvable problem, at least until we have so sophisticated AI that it can reliably decide when root access is being used for evil vs when it's being used legitimely.
However, the HT-related security problems can be solved without any noticeable performance hit, so there's no reason to put up with disabling HT entirely.
Nevertheless, there is an official kernel which carries more weight than others, and Linus is in charge of it. That could be changed so that people vote on what goes into the kernel, perhaps with a well-defined policy for what's OK, so that votes don't have to take place in simple cases. But it doesn't, so people complain.
If I read the article correctly, this problem would affect all multiprocessor systems to various degrees. In which case Linus is right; the solution will have to be very, very carefully designed to hit all the possible problems at once, or it won't be worth doing. It may require some hardware assist from the CPU manufacturers if a fool-proof solution is to be found.
Yeah -- Just like in Communist Cuba, where everyone is equal and has equal access to wealth and privilege [not!].
Theory is one thing, practice is another.
Everyone can make changes, but will those changes ever get supported in the mainstream? It's a common misconception in the less informed ranks of the Open Source community that "anyone" (like my Aunt May, or grandma in a nursing home) can take a copy of an open source project, modify it to do what they want and recompile it and have something useful.
Even if they could intelligently modify it, does "everyone" get the resources to fix bugs and add features to the new "fork"? Of course not. How many kernel developers can be "forked" (duplicated in full) to work on a new source fork for "everybody" who wants a slight mod here or there.
The linux-kernel is, in my own experience, one of the easier projects to build (on x86 on a Gnu-Linux based OS). It has few (none?) external source dependencies and the development tools are included in the major, if not all distros.
However, many OSS projects just "assume" you already have packages "X, Y & Z" installed or have the source for those projects installed in the same build tree, or the development headers & libs (at a, sometimes unspecified, specified "version") from other products installed to compile and link against. OSS-Linux-kernel based vendors are sometimes better about this -- like including build-time checks for specific packages being installed, but that "help" can be annoying if you aren't wanting to build the product in the same config as the vendor did.
You can't clone the entire development effort of the Linux kernel by simply having the ability to physically copy the source. It requires a huge knowledge base to maintain, fix bugs in to add new hardware support, not to mention "new" features (like improved VM's, Filesystems, etc...).
-l