On Sunday 17 April 2016 17:27:05 H. Peter Anvin wrote:
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.
it's unnecessary complex, which means it is more likely to have bugs in
it
besides, it's still feeding CSPRNG output to CSPRNG, no matter if it
reads the bits from /dev/random or /dev/urandom
kernel will not provide you with raw random values it gathered
so again, why block users from setting the randomness source to value
they think is sufficient for their use case?
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web:
www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic