Differences between revisions 13 and 14
Revision 13 as of 2020-01-28 19:28:08
Size: 2799
Comment: reorganize references to userspace jitter entropy collectors
Revision 14 as of 2020-01-28 19:40:17
Size: 3281
Comment: 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.

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

Buster release-notes

Keywords

boot-time delay, crng, hang, getrandom, randomness, systemd