By passthrough I did not mean hardware access. Just in the conventional
sense “passed thorough from host to VM” (even if moderated through virtio).
HulaHoop via Whonix Forum:
FIxed, as in the quality of their entropy is now equal but the blocking behavior which can impact the performance of crypto apps is still very much prevalent AFAIK. The guest kernel version is a moot point since the entropy is being directly injected from the host.
The /dev/random page (was updated) still saying:
/dev/random is suitable for applications that need high quality
randomness, and can afford indeterminate delays.
And.
When read during early boot time, /dev/urandom may return data prior
to the entropy pool being initialized. If this is of concern in your
application, use getrandom(2) or /dev/random instead.
So /dev/urandom is still more risky than /dev/random.
By using urandom you make sure that it is very hard for a rogue app
in the guest to DoS the RNG interface.
The threat model being, the VM running malware exhausting the host’s
/dev/random?
Is this possible nowadays?
I think, unfortunately there might be many ways for a VM to DOS the host
operating system. Reference:
That topic could certainly use stress testing.
The compromise here might be the VM having lower quality entropy versus
protecting the host from /dev/random overuse.
Can virtio moderate this?
Ancient kernels on the host? Unlikely and they would have bigger security problems.
The guest? Immaterial since the source of the entropy is the improved RNG in more recent kernels and jitter-rng acts as a last line of defense in case someone is so inebriated as to run both an old host and guest.
As many good sources of entropy, the better. As good as jitter-rng might
be, /dev/random might still be higher quality than /dev/urandom. So best
to have two high quality sources of entropy and not one only 1.
Also, the switch from random to urandom was done by upstream for any default new VM template.
It might be the case that upstream is not be diving as deep into the
entropy topic.