[Qemu-devel] RFC: virtio-rng and /dev/urandom

[Qemu-devel] RFC: virtio-rng and /dev/urandom

[Cole Robinson]

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

Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom

[Richard W.M. Jones]

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?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

Re: [Qemu-devel] [libvirt] RFC: virtio-rng and /dev/urandom

[Richard W.M. Jones]

On Fri, Apr 15, 2016 at 12:46:46PM +0100, 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.

I should clarify I mean: *after* the pool has been initialized with
sufficient entropy in the first place (which happens very early in
boot), you can then read almost indefinitely.

Rich.

> Steve: can we disclose the research that was done into this?  If so
> can you summarise the results for us?
> 
> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-p2v converts physical machines to virtual machines.  Boot with a
> live CD or over the network (PXE) and turn machines into KVM guests.
> http://libguestfs.org/virt-v2v
> 
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/

Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1733 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom

[H. Peter Anvin]

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.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom

[Hubert Kario]

[-- Attachment #1: Type: text/plain, Size: 2020 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom

[Hubert Kario]

[-- Attachment #1: Type: text/plain, Size: 1756 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom

[H. Peter Anvin]

On April 15, 2016 9:10:44 AM PDT, Hubert Kario <hkario@redhat.com> wrote:
>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.

That's not the point.  The point is that it is a complete waste of resources when the PRNG can simply be run in the guest
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom

[H. Peter Anvin]

On April 15, 2016 9:10:44 AM PDT, Hubert Kario <hkario@redhat.com> wrote:
>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.

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.

Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom

[Paolo Bonzini]

> 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 ;)

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.

Paolo

Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom

[H. Peter Anvin]

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

Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom

[H. Peter Anvin]

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.

This also ties into the proposed MSR to support kASLR in the guest in
the absence of rdrand/rdseed.  Using virtio in that phase of bootup is
generally not feasible.

	-hpa

Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom

[Daniel P. Berrange]

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

Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom

[H. Peter Anvin]

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.

Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom

[Hubert Kario]

[-- Attachment #1: Type: text/plain, Size: 3565 bytes --]

On Friday 15 April 2016 17:51:36 H. Peter Anvin wrote:
> On April 15, 2016 9:10:44 AM PDT, Hubert Kario <hkario@redhat.com> 
wrote:
> >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.htm
> >> > l
> >
> >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.ht
> >> > ml
> >> > http://www.redhat.com/archives/libvir-list/2016-April/msg00186.ht
> >> > ml
> >> > 
> >> > 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.

Since when "wasting resources" is worse than performing Denial of 
Service on your own infrastructure?

Besides, what's the difference between spinning a CSPRNG in host rather 
that guest? If anything, spinning CSPRNG in host is less of a waste as 
the virtualisation overhead (however small) isn't there. If you need X 
number of random bytes, you need to provide X number of random bytes. 
The software simply won't work otherwise.

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

We did discuss it with NIST, have you?

The refill policy doesn't matter, after the pool is seeded, it will 
continue generating unpredictable random numbers for years (if not 
decades or centuries) without any additional entropy. And you certainly 
will gather enough entropy to reseed /dev/urandom multiple times an 
hour, even if the host does not do anything but generate random numbers.

> 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 ;)

Not everybody is running on newer Intel, not everybody is even running 
on x86_64 architecture. Not everybody trusts the RNG in Intel hardware 
(e.g. rdrand is a not-Approved algorithm for FIPS certified software).
-- 
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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom

[Hubert Kario]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom

[Hubert Kario]

[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom

[Daniel P. Berrange]

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

Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom

[H. Peter Anvin]

On April 18, 2016 4:26:24 AM PDT, "Daniel P. Berrange" <berrange@redhat.com> wrote:
>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

There are multiple machines, and there are snapshots restored.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

Re: [Qemu-devel] [libvirt] RFC: virtio-rng and /dev/urandom

[Yaniv Kaul]

[-- Attachment #1: Type: text/plain, Size: 2147 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 3844 bytes --]

Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom

[Cole Robinson]

On 04/15/2016 06: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?
> 
> 2) regardless of #1, should we continue to reject that config in libvirt?
> 

Even though there's still a debate about whether use of /dev/urandom here is
sensible, several people suggested removing the libvirt path restriction, and
nobody really spoke up to defend it. So I've posted a patch to fully drop
libvirt's rng path whitelist:

http://www.redhat.com/archives/libvir-list/2016-April/msg01362.html

- Cole

Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom

[Steve Grubb]

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