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."

Comments

Re:you have the source

[AndroSyn]

It's not as simple as just commenting out a few lines of code.

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:At Least He Doesn't Throw Chairs

[oztiks]

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:you have the source

[TechyImmigrant]

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.