Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)

[Jeff Garzik <jgarzik@pobox.com>]

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