Slashdot Mirror
Linus Responds To RdRand Petition With Scorn
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."
I think it's more likely that the RDRAND thing has been an ongoing argument/flamewar for a long time. See this thread 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.
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.
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.
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.
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.
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.
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.
Slashdot - News for Nerds, Stuff that Matters, in ISO-8859-1 Has just realised that beta makes this signature redundant
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? Why isn't there a petition to have that removed...?
Moderation Total: -1 Troll, +3 Goat
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.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
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; try it yourself if you want.