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

Bug #1811758 reported by dkg on 2019-01-15
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
QEMU
Wishlist
Unassigned

Bug Description

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.

dkg (dkg0) wrote :

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.

dkg (dkg0) wrote :

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.

Thomas Huth (th-huth) wrote :

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.

Changed in qemu:
importance: Undecided → Wishlist
Amit Shah (amitshah) wrote :

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers