On April 18, 2016 2:28:42 AM PDT, "Daniel P. Berrange"
<berrange(a)redhat.com> wrote:
On Fri, Apr 15, 2016 at 08:56:59AM -0700, H. Peter Anvin wrote:
> On April 15, 2016 3:41:34 AM PDT, Cole Robinson <crobinso(a)redhat.com>
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?
> >
> >Thanks,
> >Cole
>
> Using /dev/urandom for virtio-rng, *except* perhaps for a small seed,
> it a complete waste of cycles. There is absolutely no reason to have
> one prng feed another.
Regardless of the performance aspect, the key question we need the
answer to is whether it *cryptographically safe* to use /dev/urandom
on the host to feed virtio-rng. The original discussion said it was
/unsafe/ to use /dev/urandom, hence why we do not allow it. If the
only downside is wasted performance, then it is reasonable to allow
the user to use /dev/urandom if they so wish.
Regards,
Daniel
Perhaps. What we do know is that it at least used to be a fairly common misconfiguration;
up there with people who would feed /dev/urandom to rngd!
Probably there ought to be a backend which knows to use urandom for a seed and then fall
back to random, rather than simply relying on a file name.
Another thing that really needs to be addressed, but is a separate issue: invalidating and
reseeding the entropy pool after a snapshot event.
--
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.