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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list