Linus Responds To RdRand Petition With Scorn 566
hypnosec writes "Linus Torvalds, in response to a petition on Change.org to remove RdRand from /dev/random, has lambasted the petitioner by called him ignorant for not understanding the code in the Linux Kernel. Kyle Condon from the UK raised a petition on Change.org to get Linus to remove RdRand from /dev/random in a bid 'to improve the overall security of the linux kernel.' In his response, Torvalds asked Condon and the supporters of the petition to gain an understanding of Linux drivers and cryptography, and then 'come back here and admit to the world that you were wrong.' Torvalds stressed that kernel maintainers knew what they were doing and the petitioner didn't. Torvalds, in a similar outburst just yesterday, hoped that 'ARM SoC hardware designers all die in some incredibly painful accident.' This came in response to a message from Kevin Hilman when he noted that there were quite a few conflicts in the ARM SoC pull request for Linux 3.12 which were a result of the platform changes conflicting with driver changes going in to the V4L tree."
Re:Marital/Money problems??? (Score:5, Informative)
I think it's more likely that the RDRAND thing has been an ongoing argument/flamewar for a long time. See this thread [google.com] for an example.
BTW Linus is right. According to what we know about randomness, even if RDRAND is hacked then mixing it with other entropy can't hurt - at worst, it merely is a no-op and achieves nothing. However, even if RDRAND is backdoored, the NSA is not the worlds only adversary. Given that when mixed with other randomness it doesn't hurt, it's still better to use it against all the other adversaries out there than not.
Linus' point is, exclusive reliance on RDRAND would be bad, but the kernel doesn't/shouldn't do that.
Re:Marital/Money problems??? (Score:5, Informative)
Based on what?
He has always spoken this way to those who deserved it. Notice he does not go after noobs or people who do not ask for it. If you put up a petition to get something changed, you should at least know what you are talking about.
Re:Got your feelings hurt? (Score:5, Informative)
How about reading his responses?
Taken out of context, those are death threats, in context however, it's just (misguided?) ventilation. He just ventilates and says that it's a pile of poo and he really wish they would stop doing that, he then goes on, in an uncanny (for him) reasonable response on how, they should handle pull requests in the future.
Grepping our own source tree for fuck, crap, shit, die, stupid will return quite a lot of ventilation and quite often directed at the sales department. Veteran programmers are grumpy old bastards, live with it or get off our lawn.
Re:you have the source (Score:5, Informative)
No, it's easier than that. You can simply pass nordrand to the kernel. It was the first thing I saw when I opened up
arch/x86/kernel/cpu/rdrand.c
__setup("nordrand", x86_rdrand_setup);
So there...don't like rdrand, don't use it.
From Documentation/kernel-parameters.txt
nordrand [X86] Disable the direct use of the RDRAND
instruction even if it is supported by the
processor. RDRAND is still available to user
space applications.
Re:Marital/Money problems??? (Score:5, Informative)
He has always spoken this way to those who deserved it.
From his perspective. I would assert he has as little business talking about ARM SoC hardware designers about their design decisions as they have of telling him how to design an OS.
Anyone who has worked between chip and software teams knows the fights here are epic and unending.
Re:That's uncalled for, really. (Score:3, Informative)
If you ever have to deal with Linux on ARM without a ready-made distribution for just your system, you will understand the sentiment. Non-discoverable buses are indeed shit. Having to manually tell the OS where everything is was tolerable in the 90s, you know, before something as initially broken as plug-and-play was cause for joy because you no longer had to use dip switches to set conflict-free addresses that you then had to copy into the BIOS setup and every application, and hope that someone hadn't hardcoded the port number for the Soundblaster card.
Re:you have the source (Score:4, Informative)
You don't need your own tree. Its mature area of the kernel. You just keep your patch and once in blue moon modify it slightly if some day it stops applying cleanly.
Re:Why all the whining in the first place? (Score:4, Informative)
Well I think I would know about it if it was. I don't recollect the NSA leaning on me to put backdoors in there when I was designing it.
Re:At Least He Doesn't Throw Chairs (Score:5, Informative)
He didn't create anything. ANYTHING. Open source existed before Torvalds. UNIX existed before Torvalds. To use the infamous battle cry of the typical Slashdork... "Where's teh innovationz?!?!?111!!?"
I've been using Linux since 1993. I can't even begin to tell you how wrong you are :) Oh the memories ... 14.4 modems, 386 DX!! (yes, none of those pussy SX processors), Hercules monitors and MFM harddisks!
When people start treating it like a valid technology instead of a religious movement it'll get more momentum in the mainstream.
You're missing the point. It's not treated as a religious movement It's kind of more like being a 60s child in the modern day if that makes sense.
When people start worrying about advancing Linux over where it stands versus Microsoft or Apple it'll finally have the chance of taking great leaps forward.
Google wrapped a business model around Linux. It's called Android and it's doing just fine.
Re:Got your feelings hurt? (Score:5, Informative)
Here's what he wrote:
Linus is not usually my cup of tea, and the sprinkling of personal attacks doesn't help his case. But it's a reasonable explanation of why /dev/random works the way it does and why it won't be changed.
Re:Got your feelings hurt? (Score:5, Informative)
These days, almost every time a story is posted along the lines of "Linux says X" it's frequently framed in such a way as to paint Linus as a frothing madman hurling not just insults but entire furniture factories at his cringing subordinates. It's become such a regular occurence that I half expect them to be followed up with a story on how Steve Ballmer has converted to buddhism and will be using the armpit sweat from his meditations to irrigate the sahara.
Reading the article, of course, usually reveals a different picture, but that gets in the way of attention-grabbing headlines. I'm not really sure how the following post can be construed as "fury"; irritation, indignation, perhaps, but not fury.
Where do I start a petition to raise the IQ and kernel knowledge of people? Guys, go read drivers/char/random.c. Then, learn about cryptography. Finally, come back here and admit to the world that you were wrong. Short answer: we actually know what we are doing. You don't. Long answer: we use rdrand as _one_ of many inputs into the random pool, and we use it as a way to _improve_ that random pool. So even if rdrand were to be back-doored by the NSA, our use of rdrand actually improves the quality of the random numbers you get from /dev/random. Really short answer: you're ignorant.
As far as I can tell, no-one's found any evidence for rdrand being backdoored, and even if it were, there's bigger issues at foot with things like microcode. Linus explains how the kernel implementation uses random data from several different sources to guard against this kind of stuff. Plus, as other people have pointed out, you can disable rdrand with a kernel parameter. Linus is primarily a pragmatist, so it doesn't really make much sense to excise the code from the kernel - throwing out the baby with the bathwater if you will. Surely if there were any hardware to worry about, it'd be the hardware providing AES-NI [intel.com]? Why isn't there a petition to have that removed...?
Re:At Least He Doesn't Throw Chairs (Score:4, Informative)
Not to make it a dick measuring competition on Tovalds behalf but you look at the guy on the other side of the fence who made staggeringly more [celebritynetworth.com].
Besides, we wont mention that this person in question has since then retired and is still making literally 100x more per year than Tovalds. I get your point but relatively speaking, If Tovalds chose to sell out how much more could [of] he made/make?
Re:you have the source (Score:4, Informative)
Kyle Condon here, the reason I started the petition was not because I was too lazy to do it myself. I know C and could quite easily compile my own kernel with the functionality taken out. However, the petition was to have it removed from the MAINLINE linux kernel, this would remove it for everyone who ran the linux kernel and not just the select few who had enough knowledge to turn it off.
Re:you have the source (Score:4, Informative)
> Is there even a way for the OS to prevent applications from using this instruction?
Yes. You use your OSly powers to be the hypervisor and put a VM trap on the instruction. Then rather than returning a random number you return an #undef or a non random number or a zero with the carry flag clear.
Don't trust a VM that traps RdRand. It is out to get you.
Re:At Least He Doesn't Throw Chairs (Score:3, Informative)
I take it from your posts which contain slight spelling and grammar affectations (but are otherwise coherent) that English is not your native language.
You may wish to make note of the following:
"I have made over $10,000,000 this year."
"I of made over $10,000,000 this year."
These statements are not equivalent and one of them is actually nonsense.
"I could have made over $10,000,000 this year."
"I could of made over $10,000,000 this year."
Likewise with these statements.
"I could've made over $10,000,000 this year."
This is pronounced as "could uv", but I assure you that the 've is a contraction for "have". Many less educated native English speakers make this mistake, so you'll likely want to avoid it when possible.
Re:"I hope that ARM SoC hardware designers all die (Score:4, Informative)
Just the ones who put in non discoverable busses. So he got that one about right,
Re:Negotiation Skills (Score:5, Informative)
And by disabling RdRand, you can only decrease security, so it would be pretty stupid to do so. But that requires actually understanding how an entropy pool works, something the petitioner does not. Basically, the only sane reason to disable it is for tests.
In fact of the sheer stupidity of the request, Linus was pretty friendly in its answer. He is also 100% right.
If you look at what Intel apparently wanted, namely drop the entropy pool and only use RdRandom (https://plus.google.com/117091380454742934025/posts/SDcoemc9V3J), _that_ would have been highly problematic. But Theodore Ts'o actually understands how these things work and refused. I thought it was a pretty good call back then (and I seem to remember that Linus called this one wrong but learned better), and now it looks like it prevented a world of trouble. On the other hand, we now have strong indication that some Intel engineers have been compromised by the NSA.
Re:you have the source (Score:5, Informative)
Yes. But I'm not going to give a well researched answer because I'm about to get on a plane.
Primarily the problem is that the Linux kernel RNG exists in many contexts and trusts that its random sources are random across all those contexts. This has been found to be false. The factorable.net study showing re-used primes between certs created on low-entropy router devices is an example of what can go wrong.
There are other more detailed things. The pool entropy calculations are flat out wrong. They are less wrong after Peter Anvin submitted a patch to have it do a piecwise approximation to a shannon entropy sum rather than an arithmetic sum, but it's not doing anything like a normal min-entropy computation for an entropy extraction algorithm.
The kernel trusts userland programs to be honest about the entropy in the sources. E.G. RNGd. However RNGd and other entropy gather daemon's have no basis on which to know the source entropy and so they make it up. The kernel takes this number and uses it in the pool entropy calculation. And so the whole calculation is built on sand.
The behavior of the kernel results in boot time entropy starvation, right at the point where you need it most.
This is RdRand changes the picture somewhat. The entropy source is well modeled and its min entropy is know. The resulting entropy from the condition is therefore known. The entropy seeding the DRBG is therefore know. It is therefore known how to extract full entropy output from RdRand, and it is known what the cryptographic resistance to brute for attack is (which is not quite the same thing). Such a chain of reasoning is what a good RNG should have.
You are better off using RdRand because it's available from the first instruction executed. It has known properties and the resulting numbers are not subject to the timing, memory API attacks that the kernel RNG numbers are subject to on the long winding path from device to RNGd to kernel API to kernel RNG to /dev/random to userland library to userland application.
Re:Here's your debate (Score:5, Informative)
Then how do you know the software RNG in the kernel is random? By using randomness tests, that's how, like the diehard suite. Diehard has been run on RdRand [blogspot.com]; try it yourself if you want.
Evil Things RDRAND Could Do (Score:4, Informative)
Yes, RDRAND could do evil things. It could go play Towers of Hanoi when you execute it. It could Halt and Catch Fire. It could email your MAC address to the KGB. So could any other instruction, if Intel wanted to be malicious, just when you thought it was safe to go back in the register pool.
If the NSA has convinced Intel to do evil things with RDRAND, the most likely one would be to hand out low-quality entropy when claiming that it's high-quality. It's still useful, and like any entropy source, it shouldn't be the only entropy source you use, and you shouldn't use it without hashing it together with a bunch of other hopefully-not-broken entropy. But it's still useful, and as somebody said, the NSA isn't your only enemy.
Especially when you're starting up a machine (physical or virtual), you really need good entropy and you don't have a lot of sources available yet. If you don't trust RDRAND, or even if you do, hash it together with some secret password and the clock and whatever else you've got.
Re:you have the source (Score:4, Informative)
The petition, this thread and the comment you replied to were all talking about the kernel and the random numbers it provides through /dev/random. So, in the context of this discussion, passing an argument to the kernel does disable RDRAND completely. This is a bit too obvious to believe you're arguing in good faith here.
Indeed.
Re:Time for an entropy server? (Score:4, Informative)
It's an unreasonable idea. First, it requires a reliable Internet connection. Second, the NSA could monitor the traffic, plant back doors in the server, or otherwise compromise an in-the-cloud solution.
Much better would be a hardware source of randomness, connected to your server, and under your direct control.
Why not get a cheap webcam and set up your own LavaRnd? There, true random data available to your computer even at boot time.
http://www.lavarnd.org/what/how-good.html [lavarnd.org]
LavaRnd has Linux kernel drivers, and it will drop right in and Just Work.
I'll donate $1000 towards costs if the idea is viable.
You could buy a lot of cheap webcams for $1000.
Re:Here's your debate (Score:2, Informative)
No, black-box RNGs and PRNGs cannot feasibly be verified, beyond ruling out particularly bad cases. Passing Diehard is a good start, but designing a stream that can pass Diehard while being 100% predictable is cake -- applying any strong block encryption to the values (1,2,3,...) in sequence ought to work. If you want people to trust your RNG or PRNG, you need to open up the design and let the appropriate experts (cryptographers, scientists, whatever) take a crack at it. A system that is mass produced isn't secure unless it's secure even when the whole system is understood (except for the secret key, for systems whose security is meant to depend on that).
However, the grandparent comment saying RdRand should be discarded is also off-base, as a commenter on the site already pointed out. RdRand is only a liability if it interacts negatively with the other sources it is XORed with, and that would be difficult to pull off -- it almost implies that the RdRand implementation understands its role in the larger program and knows how to subvert that. Not impossible, but unlikely.