On Fri, Mar 25, 2005 at 04:50:16PM -0600, Kim Phillips wrote:
> I did some tests and found that the udelay(200) call in hw_random.c is
> not good for extreme RNG consumption. Whether or not such extremes
> occur in real life, on the mpc8541, /dev/hwrandom is an order of
> magnitude slower than /dev/random, and two orders of magnitude slower
> than /dev/urandom. The hardware RNG is capable of exceeding software
> /dev/random speeds plus it would alleviate the core to do other, more
> useful things (that's being realistic).
Consider what an RNG does: spews garbage.
In practical applications, you -do not- want to dedicate the machine to
spewing garbage. The vast majority of users would prefer to use their
machines for real stuff. Thus, "extreme RNG consumption" is largely
irrelevant to sane usage.
That said, I cannot remember if the udelay() is hardcoding a policy
decision (bad), or required for the hardware.
In any case, it is the wrong solution to simply "turn on the tap" and
let the RNG spew data. There needs to be a limiting factor... typically
rngd should figure out when /dev/random needs more entropy, or simply
delay a little bit between entropy collection/stuffing runs.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]