Re: [RFD] Direct support for the x86 RDRAND instruction

["H. Peter Anvin" <hpa@linux.intel.com>]

On 07/29/2011 02:05 PM, Jeff Garzik wrote:
> 
> This does not cover the one question I [predictably] have:  why not do 
> this in rngd, rather than the kernel?
> 

That is actually why I didn't do the /dev/random aspect of this.  I have
an rngd enabling patch in the works as well.

The reason for not using RDRAND *only* in rngd is that it is a poor
match -- RDRAND is designed as a /dev/urandom-type replacement, but it
is *way* faster than the in-kernel system (since it is all in
hardware)... plus it is reseeded far more frequently than what is
possible in software (the architectural spec guarantees a reseed every
512 reads; I am told by the hardware people that in reality it is way
more frequent than that.)

For /dev/random, we do want to be hyper-conservative, though.  rngd in
its current form doesn't deal with fractional entropy, which means
boiling it down to guaranteed pure entropy; this is an enormous data
reduction and about three orders of magnitude reduction in bandwidth.
For /dev/random, I think that is just fine; after all, if you're asking
for /dev/random, you're asking for security at every cost.

> Since many (all?) TPM chips include a random number generator, Dell has 
> made sure that most distros have a useful copy of the rng-tools 
> userspace pkg I've been maintaining.
> 
> It would seem straightforward to add this to rngd, and enable RDRAND on 
> older distros and kernels, as well as current distros / kernels.  This 
> also gets useful entropy to /dev/random as part of normal operation, 
> rather than only merely speeding up /dev/urandom.
> 
> Though for the record, I do agree that this is a nice, small and clean 
> kernel implementation.

As previously stated, I have that patch in the works as well.

	-hpa