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