I’m not really the best person to ask as entropy is not my forte but I don’t see why this would matter from a security perspective unless there is some vulnerability in RDRAND (which isn’t just a theoretical concern). Even then, it won’t matter much as RDRAND isn’t the only source of entropy.
linux-hardened and ClipOS both disable CONFIG_RANDOM_TRUST_CPU. I think we should look into this more.
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.
General good read about entropy:
Excellent writeup by systemd:
After reading above I concluded that flipping the wrong setting could worsen entropy, specifically in VMs.
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.
random.trust_cpu=off as a boot parameter to disable it.
Dunno what that does. Can’t find any documentation.
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.
Just less entropy which is obvious.
I’m not seeing any significant performance decrease.
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.
Though one detail.
jitterentropy-rng as much as it is appreciated… Its user space daemon starts too late and jitterentropy-rng kernel module “doesn’t do much”.
Even with jitterentropy-rng, CONFIG_RANDOM_TRUST_CPU is wrong since iy gives rdrand a privileged position in entropy seeding.
That’s not the meaning I understood:
This instance is currently (barring the acceptance of ) 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.
@HulaHoop That is an important point to bring to the community’s attention ,many may not be aware.
Everyone seems to agree that this isn’t a good idea so I’ve created pull requests to disable this in security-misc and hardened-vm-kernel.
anontor via Whonix Forum:
And also going with what you said HulaHoop, it could end up hurting the user if applied improperly
I don’t see how. / I don’t get that one.
The critical point is:
(barring the acceptance of 
And  is not yet accepted.
Other quotes that indicate that:
The in-kernel DRBG currently is only used to support the IV generation as part
I guess you can answer your question now yourself: if you need the
in-kernel DRBG, you want the jitterentropy_rng statically in the kernel.
Given the answer above, I think it is clear that building it as a module will
most likely defeat the intent of it.
Currenlty it is build as a module by Debian kernel default.
Modules load through /etc/modprobe.d or /usr/lib/modules-load.d/ are load at at much later time than initial entropy pool seeding.
I wouldn’t know how that would be possible. Please elaborate / link to references.
Following whatever version Debian uses. Depending on which version of Debian will be used as basis for Whonix. No systemd version specialties.
At time of writing https://packages.debian.org/buster/systemd is
5.1.4. Daemons fail to start or system appears to hang during boot
systemdneeding 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
amd64systems supporting the
RDRANDinstruction this issue is avoided by the Debian kernel using this instruction by default (
amd64systems and some types of virtual machines need to provide a different source of entropy to continue fast booting.
havegedhas 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
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:
- no human noticeable performance difference by our testers on host and in VMs.
- https://lists.debian.org/debian-security-announce/2008/msg00152.html [archive]
- Lessons from the Debian/OpenSSL Fiasco [archive]
@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.