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.
As far as a human noticeable delay, there was none.
When I actually timed the boot from initial loading of ramdisk to the lightdm sign in screen, the real difference was just under 3 seconds.
And dmesg ackknowledges the difference as well. When reviewing the boot logs, with the parameter set, urandom was used and 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).
Also, I made sure for both times to have SSH and OpenVPN@server.service set as enabled by systemctl just to see if any delay was happening on boot. There was no delay and both services initialized with no errors
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 as many may not be aware of that. For my day to day host system, it is Debian Buster with both haveged and jitterentropy-rngd enabled. I do not use the random.trust_cpu= kernel parameter myself, as it was just a test to see what, if any difference it makes in boot time. Not really much as it seems. And also going with what you said HulaHoop, it could end up hurting the user if applied improperly
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 have re-read this thread and the other earlier one a couple times. I believe there was a bit of confusion (on my end) regarding this cpu trust setting.
There is a kernel compile-time setting CONFIG_RANDOM_TRUST_CPU and then there is a kernel parameter setting random.trust_cpu= that would be placed on the commandline to disable the CONFIG_RANDOM_TRUST_CPU kernel compiled in setting.
From what we know, having the random trust set to “off” either from compiled in default, or commandline setting, this would disable the RDRAND engine as the sole source of early-entropy (crng). This used to be the default for Debian Stretch. For kernel 4.19 Buster, the security team decided to have the early entropy seeded by RDRAND. Boot log confirm this because after get_random_bytes is called, the message “random: crng done (trusting CPUs manufacturer)” is displayed. As an aside, other distributions like Ubuntu use this same method as well (Ubuntu uses the 188.8.131.52 kernel release for their hwe stack)
The “other” way the Stretch kernel and earlier kernels used to gather early entropy was through urandom. An upstream change with systemd is a reason why Debian now uses the method they do.
That brings us to the question of whether to follow the decision of Debian or to use the “old” method. If we are going to use systemd 241 and above, it would probably be a good idea to stick to current Debian defaults so as to avoid problems with compatability. Does this make sense and is it sane from a security standpoint? Myself, i believe it is, but I need your guys expert opinions to be sure
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. Source 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 just wanted to clear up a couple things:
I was wrong about Debian’s reasoning; the systemd issue I referred to was just a bug for certain workloads, which I believe has been worked out.
From what I could infer from their (Debian’s) wiki page, it looks like they included CONFIG_RANDOM_TRUST_CPU as default because some systems were having very long boot delays and using the hardware as a source for entropy would help mitigate that.
As far as the pre-Buster method for entropy gathering, obviously a urandom read is not the way they did it. I was wrong on that. I do have confusion about entropy, so in the meantime I will do more reading.
I did not want to mislead anyone, sorry about the mixup