Messages in this thread |  | | | Date | Fri, 29 Jul 2011 14:17:14 -0700 | | From | "H. Peter Anvin" <> | | Subject | Re: [RFD] Direct support for the x86 RDRAND instruction |
| |
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
|  |