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