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