Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom

[Hubert Kario]

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

signature.asc
Description: This is a digitally signed message part.