On April 18, 2016 2:28:42 AM PDT, "Daniel P. Berrange" <berrange@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@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.