Re: [PATCH v4 2/5] random: Add and use arch_get_rng_seed

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

On 07/22/2014 01:44 PM, Andy Lutomirski wrote:
> 
> But, if you Intel's hardware does, in fact, work as documented, then
> the current code will collect very little entropy on RDSEED-less
> hardware.  I see no great reason that we should do something weaker
> than following Intel's explicit recommendation for how to seed a PRNG
> from RDRAND.
> 

Very little entropy in the architectural worst case.  However, since we
are running single-threaded at this point, actual hardware performs
orders of magnitude better.  Since we run the mixing function (for no
particularly good reason -- it is a linear function and doesn't add
security) there will be enough delay that RDRAND will in practice catch
up and the output will be quite high quality.  Since the pool is quite
large, the likely outcome is that there will be enough randomness that
in practice we would probably be okay if *no* further entropy was ever
collected.

> Another benefit of this split is that it will potentially allow
> arch_get_rng_seed to be made to work before alternatives are run.
> There's no fundamental reason that it couldn't work *extremely* early
> in boot.  (The KASLR code is an example of how this might work.)  On
> the other hand, making arch_get_random_long work very early in boot
> would either slow down all the other callers or add a considerable
> amount of extra complexity.
> 
> So I think that this patch is a slight improvement in RNG
> initialization and will actually result in simpler code.  (And yes, if
> I submit a new version of it, I'll fix the changelog.)

There really isn't any significant reason why we could not permit
randomness initialization very early in the boot, indeed.  It has
largely been useless in the past because until the I/O system gets
initialized there is no randomness of any kind available on traditional
hardware.

	-hpa