Messages in this thread | | | From | Linus Torvalds <> | Date | Sat, 30 Jul 2011 09:29:18 -1000 | Subject | Re: [PATCH 1/2] random: Add support for architectural random hooks |
| |
On Sat, Jul 30, 2011 at 9:13 AM, Matt Mackall <mpm@selenic.com> wrote: > > Well then rather than saying my NAK doesn't matter, you should say you > also NAK it.
No, I don't think your NAK matters because your arguments were so insane.
Talking about electron microscopes and *expanding* on the patch just makes me go "that NAK is not worth worrying about".
You comparing the rdrand to 'rdtsc' is more realistic, but it still dismisses how powerful rdrand is.
The fact is, even if you worry about some back door for the NSA, or some theoretical lack of perfect 32-bit randomness, we can pretty much depend on it. We still do our own hashing on top of whatever entropy we get out of rdrand, and we would still have all our other stuff. Plus the instruction is public and testable - if Intel did something wrong, they'll be *very* embarrassed.
In other words, there's absolutely no reason not to use it, and allow us to get away from /dev/random running out of entropy. We absolutely should use it for bootup randomness (where we currently are somewhat weak), and I absolutely disagree that it should be made into more of a driver abstraction.
I'd be willing to take Peter's patch *without* the abstraction, and then just expect to cut it down.
But I'd be even more willing to just take something that just introduces a per-arch interface to get a "unsigned long *" that is random, and returning the number of bits of expected entropy in that thing. And for x86 CPU's with the RDRAND capability bit, I'd give Intel the benefit of the doubt and just make it do a single "rdrand" and return the full 64 bit (or is it a 32-bit interface? I should know, but I didn't look it up).
Of course, if there are other known random interfaces that might give more random bits, maybe "void *"+size is actually the right thing. Probably a single word is the most reasonable and simple interface in the absence of examples to the contrary, though.
Linus
| |