Can CONFIG_RANDOM_TRUST_CPU be similar be configured as a kernel parameter or sysctl?
I am asking, because until users machines will automatically re-compile their own kernel could be a long time, if ever, due to an unresolved blocker. See this very post kernel recompilation for better hardening starting from However, there is one blocker.
I tested the random.trust_cpu=off boot parameter in a “regular” Debian Buster with XFCE and also one with LXDE destops.
The actual difference was just under 3 seconds.
And dmesg acknowledges the difference also. With the parameter set, the log recognized it later on in the boot sequence (about 3 seconds). When not using the parameter, the seeding happens 3 seconds quicker and the log entry said: random : crng done (trusting cpu manufacturer).
I tried the same with both haveged and jitterentropy-rngd enabled at boot-time as well. Although they both initialized with no errors or dealys, there was no gain in saved time for boot.
The only real difference I noticed was the 3 second difference that is there if we use the boot parameter (random.trust_cpu=false). In this case there is the small delay with or without haveged and jitterentropy.
Enabling CONFIG_RANDOM_TRUST_CPU when jitter-entropy is not installed is a big mistake as it tricks systems without sufficient entropy into booting with a rigged seed instead of blocking until the pool is seeded properly. It should be disabled.
5.1.4. Daemons fail to start or system appears to hang during boot
Due to systemd needing entropy during boot and the kernel treating such calls as blocking when available entropy is low, the system may hang for minutes to hours until the randomness subsystem is sufficiently initialized ( random: crng init done ). For amd64 systems supporting the RDRAND instruction this issue is avoided by the Debian kernel using this instruction by default ( CONFIG_RANDOM_TRUST_CPU ).
Non- amd64 systems and some types of virtual machines need to provide a different source of entropy to continue fast booting. haveged has been chosen for this within the Debian Installer project and may be a valid option if hardware entropy is not available on the system. On virtual machines consider forwarding entropy from the host to the VMs via virtio_rng .
If you read this after upgrading a remote system to buster, ping the system on the network continuously as this adds entropy to the randomness pool and the system will eventually be reachable by ssh again.
This might have slipped through. People might not have seen the consequences of that change. We should write a Debian bug report asking them to disable CONFIG_RANDOM_TRUST_CPU for non-cloud environments. Here is a list of sources which may be good to be quoted to make a convincing argument:
@Patrick, thank you for the solid reply
I was wrong about Debian’s reasoning; the systemd issue was just a bug for certain workloads.
from (Debian’s) wiki page, they included CONFIG_RANDOM_TRUST_CPU to help with long boot delays
I was mistaken about the entropy gathering and did not want to mislead anyone, sorry about the mixup