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

[Ludovic Courtès]

Hello!

Marius Bakke <address@hidden> skribis:

> Ludovic Courtès <address@hidden> writes:

[...]

>> 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

Uh!  But that’s once the system is running, and with a long-enough pause
in between reads…  maybe?

>> 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/

Interesting, thanks for the link!

> Anyway, I pushed the upstream fix in
> dd6989711370c43676edc974f86c8586f21f80f6.

Coolio, now merging is no longer blocked due to entropy starvation!  :-)

Ludo’.