On Friday 15 April 2016 08:56:59 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#00 023
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.
/dev/random is a prng too, both /dev/random and /dev/urandom use exact same algorithm and yes, there are multiple reason for feeding one prng with another, all cryptographic protocols do that all the time (e.g. TLS Pseudo-Random Function output is fed as key to AES-GCM, both PRF and AES-GCM are essentially PRNGs) -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic