bug#37501: [core-updates] Entropy starvation during boot

[Marius Bakke]

Ludovic Courtès <address@hidden> writes:

> Hi,
>
> Marius Bakke <address@hidden> skribis:
>
>> I tried it, but it did not make any discernible difference in the
>> available entropy right after boot, nor did it aid the CRNG seeding.
>
> Bah, too bad, though it still doesn’t sound right to consume this much
> entropy right from the start.  I’m surprised it doesn’t make any
> difference when you remove that bit.

I guess generating 512 random bytes does not cost a lot of entropy.
Writing that made me curious, so I tested it:

$ cat /proc/sys/kernel/random/entropy_avail
3938
$ head -c 512 /dev/urandom > /dev/null && !!
3947

Wait, what?  Trying again...

$ head -c 512 /dev/urandom > /dev/null && cat 
/proc/sys/kernel/random/entropy_avail 
3693
[...typing this section of the email...]
$ head -c 512 /dev/urandom > /dev/null && cat 
/proc/sys/kernel/random/entropy_avail 
3898

> Perhaps we should print the value of /proc/…/entropy_avail in several
> places during boot time to get a better understanding.

That could be useful.  My understanding is that we were waiting for the
kernel to be absolutely certain that the entropy pool is sufficiently
random, i.e. "state 2" from this overview:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43838a23a05fbd13e47d750d3dfd77001536dd33

Once it is initialized, we get an "endless" stream of good random data
thanks to the entropy pool and ChaCha20(?).

See also this article for an overview of the discussions that lead to
Torvalds' patch:

https://lwn.net/SubscriberLink/800509/de787577364be340/

Anyway, I pushed the upstream fix in
dd6989711370c43676edc974f86c8586f21f80f6.

signature.asc
Description: PGP signature