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

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

On April 15, 2016 9:10:44 AM PDT, Hubert Kario <hkario@redhat.com> wrote:

...

On 04/15/2016 04:41 AM, Cole Robinson wrote:

...

Libvirt currently rejects using host /dev/urandom as an input

On Friday 15 April 2016 09:47:51 Eric Blake wrote: 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.

So: using urandom for a seed makes sense, but "unplugging the drain" is a huge waste of resources and provides absolutely zero value. Also, I do not believe /dev/urandom is FIPS compliant. Finally, the refill policy is different, so it is not really true the algorithm is the same. All in all, other than a seed value it really doesn't make any sense. Of course, none of this matters on newer Intel hardware ;) -- Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

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.

You should be able to crib the code from rngd (rng-tools) pretty much verbatim. -hpa

On Sunday 17 April 2016 17:27:05 H. Peter Anvin wrote:

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.

it's unnecessary complex, which means it is more likely to have bugs in it besides, it's still feeding CSPRNG output to CSPRNG, no matter if it reads the bits from /dev/random or /dev/urandom kernel will not provide you with raw random values it gathered so again, why block users from setting the randomness source to value they think is sufficient for their use case? -- 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

On Fri, Apr 15, 2016 at 6:47 PM, Eric Blake <eblake@redhat.com> 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#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.

+1 I'd personally be happy (for some specific test-dev use case) with /dev/zero - I don't care about the security, but I want the entropy collection to be done as fast as possible. Y.

-- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

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

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.

On Mon, Apr 18, 2016 at 01:07:40PM +0200, Hubert Kario wrote:

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

If you're spawning multiple machines from the same base snapshot, the seeding of RNG is just one of many many things that need dealing with. eg new /etc/machine-id, new ssh host keys, changing MAC address of NICs with corresponding guest config file changes, many other application specific identifiers / keys intended to be unique per machine. As such, libvirt explicitly tries to prevent you spawning multiple machines from the same snapshot. That all said, Microsoft HyperV has defined a concept of a "Virtual Machine Generation ID" and specified various hypervisor operations which should result in this value changing[1]. For example restoring from a snapshot should always change the genid, as would restoring from backup, or cloned from another image, or failed over during disaster recovery. This vm genid is exposed to the guest via ACPI and there's an notification whenever it changes. There are patches for QEMU[2] to support this feature in a manner that is compatible with the hyperv spec, but they are sadly still not merged :-( So it would be possible for the Linux kernel to re-initialize its RNG after snapshot by hooking into the vm-genid ACPI notification. Regards, Daniel [1] https://lists.nongnu.org/archive/html/qemu-devel/2014-10/msg00489.html [2] https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg05599.html -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|