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

[Steve Grubb <sgrubb@redhat.com>]

On Friday, April 15, 2016 12:46:46 PM Richard W.M. Jones wrote:
> On Fri, Apr 15, 2016 at 06:41:34AM -0400, Cole Robinson wrote:
> > Libvirt currently rejects using host /dev/urandom as an input source for a
> > virtio-rng device. The only accepted sources are /dev/random and
> > /dev/hwrng. This is the result of discussions on qemu-devel around when
> > the feature was first added (2013). Examples:
> > 
> > http://lists.gnu.org/archive/html/qemu-devel/2012-09/msg02387.html
> > https://lists.gnu.org/archive/html/qemu-devel/2013-03/threads.html#00023
> > 
> > libvirt's rejection of /dev/urandom has generated some complaints from
> > users:
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1074464
> > * cited: http://www.2uo.de/myths-about-urandom/
> > http://www.redhat.com/archives/libvir-list/2016-March/msg01062.html
> > http://www.redhat.com/archives/libvir-list/2016-April/msg00186.html
> > 
> > I think it's worth having another discussion about this, at least with a
> > recent argument in one place so we can put it to bed. I'm CCing a bunch of
> > people. I think the questions are:
> > 
> > 1) is the original recommendation to never use virtio-rng+/dev/urandom
> > correct?
> > 
> > 2) regardless of #1, should we continue to reject that config in libvirt?
> 
> There was a lot of internal-to-Red Hat discussion on this which I
> can't reproduce here unfortunately.  However the crux of it was that
> it's quite safe to read enormous amounts from /dev/urandom, even
> without adding any entropy at all, and use those numbers for
> cryptographic purposes.
> 
> Steve: can we disclose the research that was done into this?  If so
> can you summarise the results for us?

Joining a bit late...i was out last week. The requirement that caused the need 
for virt-rng came from Server Virtualization Protection Profile. This was also 
based on CSEG requirements in the UK. The requirement just asks if some 
entropy from the host can be made available to the guest. 

---

"FCS_ENT_EXT.1 Extended: Entropy for Virtual Machines

The TSF shall provide a mechanism to make available to VMs entropy that meets
FCS_RBG_EXT.1 through [ virtual device interface ].

The entropy need not provide high-quality entropy for every possible method 
that a VM might acquire it. The VMM must, however, provide some means for VMs 
to get sufficient entropy."

---

The fact is that urandom has entropy in it. It can be tested by

ioctl(fd, RNDGETENTCNT, &ent_count)

The idea is that the guest should be generating entropy on its own. But just 
in case there are scheduler artifacts present in the jitter and timing methods 
of harvesting entropy, we want to mix in a little entropy from the host to 
offset these effects. The requirement also does not specify how much or how 
often entropy is fed to a guest.

The requirement on the guest is that it needs to have 128 to 256 bits of 
entropy when generating a key.

-Steve