2799
Comment: reorganize references to userspace jitter entropy collectors
|
← Revision 14 as of 2020-01-28 19:40:17 ⇥
3281
describe in-kernel jitter entropy collector in Linux 5.4+
|
Deletions are marked like this. | Additions are marked like this. |
Line 13: | Line 13: |
For kernel versions < 5.4: |
|
Line 22: | Line 24: |
With Linux 5.4, an [[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=50ee7529ec4500c88f8664560770a7a1b65db72b|in kernel jitter entropy collector]] has been added that should collect enough entropy at boot time to avoid entropy-related hangs at system boot. So the issues described here should generally be resolved if you're running backports kernels on buster, or reasonably up-to-date bullseye or sid installations. |
Symptoms
Affected computers show long delays during boot, especially with applications that need randomness for initialization - including openssh, so it can leave a machine apparently dead after a Stretch-to-Buster upgrade.
If you're sitting in front of a machine that might be suffering from this problem then you may be able to speed up its recovery by jiggling the mouse. If it's a remote system, ping a network interface.
Underlying Problem
Linux is being stricter about getting urandom initialized with properly random randomness, and systemd... well, let's just say it isn't helping. As a result the system has to slowly collect entropy from other sources.
Solutions
For kernel versions < 5.4:
for amd64 CPU architectures: use a recent kernel with CONFIG_RANDOM_TRUST_CPU set (pre-Buster kernels
may need random.trust_cpu=on added to the commandline). The CPU may also need to support the RDRAND instruction; you can test whether your system currently meets these conditions with:grep CONFIG_RANDOM_TRUST_CPU /boot/config-$(uname -r) && grep rdrand /proc/cpuinfo && echo "your system looks fine"
machines with a Trusted Platform Module can use rng_core.default_quality=1000
for KVM/QEMU VMs: see Daniel Lange's summary for the required invocation to pass randomness from the host via virtio_rng
- other (unverified) sources suggest a domain configuration with
<rng model="virtio"><backend model="random">/dev/urandom</backend></rng>
- for other VMs (VMware, others that don't provide access to a virtio RNG) some other solution is needed, such as...
hardware entropy sources such as chaoskey
User-space entropy collectors, such as Thorsten Glaser's early-rng-init-tools, haveged, or others. Note that user-space entropy collection is not universally considered safe and should primarily be considered as a fallback.
With Linux 5.4, an in kernel jitter entropy collector has been added that should collect enough entropy at boot time to avoid entropy-related hangs at system boot. So the issues described here should generally be resolved if you're running backports kernels on buster, or reasonably up-to-date bullseye or sid installations.
Links
https://daniel-lange.com/archives/152-hello-buster.html
debian-devel thread: https://lists.debian.org/debian-devel/2018/12/msg00184.html, https://lists.debian.org/debian-devel/2019/01/msg00079.html
bug #912087 (bug #912616) bug #916690 bug #923675 bug #931644 bug #948519
Keywords
boot-time delay, crng, hang, getrandom, randomness, systemd