--- Begin Message ---
|
Subject: |
[core-updates] Entropy starvation during boot |
|
Date: |
Tue, 24 Sep 2019 17:48:02 +0200 |
|
User-agent: |
Notmuch/0.29.1 (https://notmuchmail.org) Emacs/26.2 (x86_64-pc-linux-gnu) |
Hello,
After reconfiguring on the 'core-updates' branch, systems using the
OpenSSH service will occasionally (not always!) hang forever during
boot, waiting for entropy. Moving the mouse or mashing the keyboard
allows the boot to proceed.
I don't think this is limited to OpenSSH, but anything that calls
getrandom() during startup.
There is some information about this problem and various workarounds
here, including links to recent LKML discussions:
https://daniel-lange.com/archives/152-hello-buster.html
For Guix, I believe adding (service urandom-seed-service-type) to
%base-services should be sufficient, but have not verified this yet.
signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#37501: [core-updates] Entropy starvation during boot |
|
Date: |
Sun, 06 Oct 2019 18:42:43 +0200 |
|
User-agent: |
Notmuch/0.29.1 (https://notmuchmail.org) Emacs/26.2 (x86_64-pc-linux-gnu) |
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
--- End Message ---