Can be considered. But we need to understand more about how entropy is bootstrapped during the early boot process. Because entropy is a difficult subject. Even more so in virtual machines.
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.
The worst case here is probably prolonged boot times. Can you find any security disadvantage? random.trust_cpu=off is probably worth trying.
If it’s not too bad performance wise, we could go for it.
There’s a lot to unpack here so this isn’t misinterpreted. Trying to describe this really well for documentation purposes.
I am not sure we can make a statement “more/less entropy”.
Maybe randomness is being collected slower during random pool initialization phase.
/dev/random should be providing same (or higher) quality of entropy during any phase.
/dev/random might be slower during random pool initialization phase. Once user space daemons are started (haveged, jitterentropy-rng), it will be same speed.
rdrand would just be 1 source of entropy. Mixed with equal priority with other sources of entropy.
We’d trade (marginally) longer booting time against less chance to get hit by an implementation flaw ot backdoor in rdrand.
Looks like an easy decision to make in favor of security.
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.
This instance is currently (barring the acceptance of [1]) only used to seed
the in-kernel DRBG in case the driver/char/random.c is not yet fully seeded.
This implies the kernel module’s purpose is to take care of the seeding in event of random.c not having completed yet.
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
Linux 5.6 introduces a kconfig for non-blocking /random for boot though blocking afterwards is still possible. Optimally Debian enables it while disabling hwrng trust.