Re: [libvirt] RFC: virtio-rng and /dev/urandom
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