Evgeniy Polyakov wrote:
On Thu, 2005-03-24 at 15:39 -0500, Jeff Garzik wrote:
Evgeniy Polyakov wrote:
hw_random.c already does it using userspace daemons,
which is bad idea for very fast HW - like VIA xstore/xcrypt
instructions.
This is incorrect, because it implies that a user would want to use the
'xstore' feature at full speed -- which would dominate the CPU,
drastically slowing down the applications that are actually doing work.
If user want to get RNG data at full speed we do not want to allow it?
Something changed in the world...
I agree with this sentiment; this is mainly a policy decision that
kernel programmers should not make.
Certainly _by default_ the RNG should not be run "full blast" all the
time. This is a needless CPU soaker.
This is another example of why the userspace rngd is useful: it is
trivial to implement "CPU soaker" policy if you wish, or use the default
"don't eat all my CPU" policy.
User actually do not want to use xstore, but only read from /dev/random.
That's a policy decision to be made by the user, not you.
Some users may wish to use RNG directly.
If kernelspace can assist and driver _knows_ in advance that data
produced is cryptographically strong, why not allow it directly
access pools?
A kernel driver cannot know in advance that the data from a hardware RNG
is truly random, unless the data itself is 100% validated beforehand.
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]
