On 04/16/16 01:31, Paolo Bonzini wrote:
Right, but there's always the point about people that use heterogeneous
hosts and cannot pass rdrand/rdseed to the guest. For these, we should
add a QEMU driver that uses rdrand/rdseed, and thus decouples virtio-rng
from the host /dev/* completely.
From the libvirt POV there are various possibilities:
- Libvirt can have a libvirt.conf parameter that says "ignore whatever is
specified in the guest XML if rdrand/rdseed is available, and instead use
rdrand/rdseed".
- Libvirt can allow specifying rdrand/rdseed _and_ an additional backend,
like this:
<backend model="cpu"/>
<backend model="random">/dev/random</backend>
and fallback to the second if rdrand/rdseed are not available.
The other thing, and this is one area where there is some legitimacy to
the /dev/urandom argument: on a fresh boot, it would be highly desirable
to get a seed value from virtio-rng even if that is "entropyless". The
backwards-compatible way would be to provide, say, 64 bytes of
/dev/urandom before switching to /dev/random, but it might be desirable
to give the guest OS some way to cause that to reset, explicitly
requesting a new seed after an in-VM guest reboot, kexec et al.
This also ties into the proposed MSR to support kASLR in the guest in
the absence of rdrand/rdseed. Using virtio in that phase of bootup is
generally not feasible.
-hpa