Given all of the VMs that Qubes manages, do entropy stores get depleted faster than a standard OS? Or do individual VMs manage their own entropy pools? My understanding is the randomness is seeded by hardware processes that generate random noise. How are VM entropy pools generated and maintained when they are typically isolated from hardware?
In the past, on other operating systems, I have “topped” off /dev/random with my hardware TRNG. Would there be any practical benefit in doing that in dom0? It would of course mean that I would need to grant access to the device to modify dom0. I trust the device (at least as much as I trust any other device I own) but not if there is no practical benefit.
If individual VMs manage their own entropy, I assume I would top off /dev/random in each of my VM templates? That being the case, do appVMs that are generated by the same template share a common entropy pool? What happens when randomness is used by a given appVM and then restarted? Does the newly launched appVM re-inheret the same entropy pool from the previous boot?
Given a trusted hardware TRNG, is there potential benefit to topping off /dev/random in a given appVM prior to batch-generating multiple cryptographic keys or running processes that require adequate stores of entropy? Or is it dom0 that needs the “refill” so that Xen can somehow seed VM instances?
Most of the available discussions on this topic are 7-10 years old. They warn of potential problems with low entropy in VMs, shared random seeds by VMs that have a common template and other security issues. But they also speak of possible upgrades that will address those problems. Have those issues been addressed over the years?
I’m also not entirely clear how dom0 and Xen interact with templates to ensure that entropy pools are not constantly reused and/or if VM instances somehow take care of that (even though they supposedly inherit the root directory of a template…)
As such, it’s not clear what is the best approach to ensuring adequate entropy in all VMs. Should something run in dom0, VM templates or in each individual instance of a VM?
Currently I plan to use rng-tools-debian to manage my hardware TRNG in individual instances of VMs. So at the very least, if I am signing blockchain transactions or creating new PGP keys, I will make a point to use the TRNG to “top off” /dev/random or specifically point to /dev/ as the entropy source.
But I am still concerned about VMs sharing randomness in general (mostly for TLS, Tor and other network applications). I used the “clone” feature a lot when setting up various templates without much consideration about entropy. I am concerned that many of my VMs might be launching with the same /dev/random directories. Is this a legit concern or does that somehow get resolved over time as VMs are continuously rebooted?
In 4.0, haveged takes care of VM entropy, in 4.1 it is done by the kernel (functionality similar to haveged went mainline in newer kernels). Seeding happens from dom0 during VM boot.
The issue also mentions various methods to estimate the available entropy.
Btw in 4.0 at least my dom0 was entropy starving. So you might want to check on that and install something like haveged as needed.
IIRC both haveged and jitterentropy-rngd use algorithms that feed CPU jitter into /dev/random / the kernel. Newer kernel versions use a similar algorithm to do that themselves (even though the author jitterentropy appears to consider it suboptimal on the aforementioned qubes issue). If you don’t trust CPU jitter as main entropy source, there might be other solutions (e.g. hardware RNG) that additionally feed into /dev/random.
