device: 0.828
performance: 0.811
semantic: 0.731
network: 0.726
files: 0.661
PID: 0.650
vnc: 0.644
other: 0.640
socket: 0.639
permissions: 0.537
graphic: 0.513
boot: 0.395
KVM: 0.295
debug: 0.201

virtio-rng backend should use getentropy() syscall when available

According to https://wiki.qemu.org/Features/VirtIORNG the default backend for `virtio-rng-pci` is `/dev/random`.  Alternately, the user can point it to a different backend file, like `/dev/urandom`.

However, both of these files have suboptimal behavior in one way or another, as documented in `random(7)`.  Instead, the default behavior should be to pull the requested octets from the `getrandom()` system call, if available, called with no flags set.

To be clear, the problem with using /dev/urandom as a backend is that it's possible to feed data from an uninitialized pool into the guest.

and the problem with using /dev/random as a backend is that it's possible for a guest to starve the other host (and other guests) of entropy, since it pulls from the blocking pool.

getrandom() only blocks when the CSPRNG is not initialized, otherwise it never blocks.  this is the right behavior by default.

any word on this?  If this is not considered for adoption, i would like to know the reason, so that we can have better predictions about what to do for entropy in a QEMU system.

Feel free to send some patches to implement this! Alternatively, you could also try to write a mail to the virtio-rng maintainer (see the MAINTAINER file in the top directory of the sources), maybe he can help.

Yes, using getrandom() in qemu by default on systems that support it will be an improvement, and is the right approach.

rng-builtin is the new RNG default backend for virtio-rng and is based on getrandom().

0198c2621a1e virtio-rng: change default backend to rng-builtin
5f7655f6ef15 virtio-rng: Keep the default backend out of VirtIORNGConf
6c4e9d487fea rng-builtin: add an RNG backend that uses qemu_guest_getrandom()