Messages in this thread | | | From | Linus Torvalds <> | Date | Fri, 29 Jul 2011 23:20:40 -0700 | Subject | Re: [PATCH 1/2] random: Add support for architectural random hooks |
| |
On Fri, Jul 29, 2011 at 2:16 PM, Matt Mackall <mpm@selenic.com> wrote: > > I have already NAKed this approach in no uncertain terms.
Doesn't matter.
Talking about "standard hardware random number drivers" is just crazy talk, when the instruction is a single instruction that takes tens of nanoseconds to run. Any driver overhead would be just crazy, and no user would ever want that anyway.
User space would never use it, because they just want to use the instruction directly.
And kernel space doesn't want it either, for the exact same reason. There's no point in making it anything but a simple direct function call, because the whole functionality is so cheap.
This is not like some stupid "behind PCI" crap. It's high bandwidth and low latency.
If anything, I think Peter's approach perhaps doesn't tie it in close enough. Instead of making it some indirect function you register, just make it an inline function per architecture that just returns how many bits of randomness it gives (default to just an inline function that returns 0 for the case of no on-CPU rng).
On x86, choice between the different possible random number generators (if somebody cares enough about the cyrix and whatever ones) could be a an asm_alternate() thing.
If you don't trust the CPU rng, don't bother with stupid arguments about electron microscopes. Test it - or more reasonably - make it just one small part of the entropy pool. But don't make it something heavy-weight, when the whole *point* of having the hardware is to make it light-weight.
Linus
| |