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?

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?

On 04/15/2016 04:41 AM, 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#0 > 0023 > > 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? That I'm not sure about - and the answer may be context-dependent (for example a FIPS user may care more than an ordinary user)

On Friday 15 April 2016 09:47:51 Eric Blake wrote: > On 04/15/2016 04:41 AM, 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#0 > > 0023 > > > > 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? > That I'm not sure about - and the answer may be context-dependent (for > example a FIPS user may care more than an ordinary user) /dev/urandom use is FIPS compliant, no FIPS-validated protocol or cryptographic primitive requires the "fresh" entropy provided by /dev/random. All primitives are designed to work with weaker entropy guarantees than what /dev/urandom provides.

Right, but there's always the point about people that use heterogeneous hosts and cannot pass rdrand/rdseed to the guest. For these, we should add a QEMU driver that uses rdrand/rdseed, and thus decouples virtio-rng from the host /dev/* completely.

On 04/16/16 01:31, Paolo Bonzini wrote: > Right, but there's always the point about people that use > heterogeneous hosts and cannot pass rdrand/rdseed to the guest. > For these, we should add a QEMU driver that uses rdrand/rdseed, and > thus decouples virtio-rng from the host /dev/* completely. > > From the libvirt POV there are various possibilities: > > - Libvirt can have a libvirt.conf parameter that says "ignore > whatever is specified in the guest XML if rdrand/rdseed is > available, and instead use rdrand/rdseed". > > - Libvirt can allow specifying rdrand/rdseed _and_ an additional > backend,> > like this: > <backend model="cpu"/> > <backend model="random">/dev/random</backend> > > and fallback to the second if rdrand/rdseed are not available. The other thing, and this is one area where there is some legitimacy to the /dev/urandom argument: on a fresh boot, it would be highly desirable to get a seed value from virtio-rng even if that is "entropyless". The backwards-compatible way would be to provide, say, 64 bytes of /dev/urandom before switching to /dev/random, but it might be desirable to give the guest OS some way to cause that to reset, explicitly requesting a new seed after an in-VM guest reboot, kexec et al.

On 04/15/2016 04:41 AM, 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? That I'm not sure about - and the answer may be context-dependent (for example a FIPS user may care more than an ordinary user) > > 2) regardless of #1, should we continue to reject that config in libvirt? This one, I have a pretty strong opinion: libvirt should NOT enforce policy. If someone has a valid use case for doing it, we should permit them to do it, even if it lets someone else shoot themselves in the foot. So I think we should relax libvirt to allow users that source their virtio-rng from /dev/urandom.

-- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

On April 15, 2016 3:41:34 AM PDT, Cole Robinson <crobinso(a)redhat.com&gt;

>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.

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&gt; 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

On Monday 18 April 2016 02:46:19 H. Peter Anvin wrote: > Another thing that really needs to be addressed, but is a separate > issue: invalidating and reseeding the entropy pool after a snapshot > event. definitely agreed though just reseeding would be sufficient - the goal is to make the output unpredictable and unique between multiple machines starting from the same snapshot, feeding enough random data to make the entropy pool unique again is sufficient to achieve that

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?