[lkml]   [2011]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/2] random: Add support for architectural random hooks
On Fri, Jul 29, 2011 at 2:16 PM, Matt Mackall <> 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.


 \ /
  Last update: 2011-07-30 08:23    [W:0.098 / U:13.408 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site