Re: [PATCH 07/10] random: add new get_random_bytes_arch() function

["Theodore Ts'o" <tytso@mit.edu>]

On Tue, Jul 24, 2012 at 08:37:23PM -0700, H. Peter Anvin wrote:
> 
> As a compromise I offer the following patch; in terms of performance
> it is "the worst of both worlds" but it should provide the combined
> security of either; even if RDRAND is completely compromised by the
> NSA, Microsoft and the Illuminati all at once it will do no worse
> than the existing code, and (since RDRAND is so much faster than the
> existing code) it has only a modest performance cost.  More
> realistically, it will let many more users take advantage of a high
> entropy quick-reseeding random number generator, thus ending up with
> a major gain in security.

RDRAND is already getting mixed in already in xfer_secondary_pool() so
we are already taking advantage of Bull Mountain (or any other
CPU/architecture-specific hw RNG) if it is present.

Aside from whether it's better to do this step in
xfer_secondary_pool() or extract_entropy(), your patch looks very
wrong to me.  Nothing is actually *using* hash.l[], which is where the
results of the RDRAND generator is placed.

I assume you were planning on xor'ing hash.w and hash.l, but that's
not present in your patch.

I also don't understand why you are using a blind union here; it has
no real advantage that I can see, and so it's all downside.  It bloats
the patch (making it harder to see that your patch results in a net
*decrease* in security, since it removes the use of RDRAND in
xfer_security_pool, and replaces it with a no-op).

		    		    	   - Ted