From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35288) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1as6uy-00026u-26 for qemu-devel@nongnu.org; Mon, 18 Apr 2016 07:00:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1as6uu-0005Rv-S8 for qemu-devel@nongnu.org; Mon, 18 Apr 2016 07:00:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35707) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1as6uu-0005Rp-FJ for qemu-devel@nongnu.org; Mon, 18 Apr 2016 07:00:32 -0400 From: Hubert Kario Date: Mon, 18 Apr 2016 13:00:22 +0200 Message-ID: <2205200.8eQElsYyJ7@pintsize.usersys.redhat.com> In-Reply-To: References: <5710C55E.3030000@redhat.com> <1627731.Y10g9rcVyf@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1648327.9lYaPWWC1R"; micalg="pgp-sha512"; protocol="application/pgp-signature" Subject: Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "H. Peter Anvin" Cc: Eric Blake , Cole Robinson , libvirt-list@redhat.com, qemu-devel , "Richard W.M. Jones" , "Daniel P. Berrange" , Peter Krempa , Amit Shah , mik@miknet.net, jjaburek@redhat.com, sgrubb@redhat.com, Paolo Bonzini --nextPart1648327.9lYaPWWC1R Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday 15 April 2016 17:51:36 H. Peter Anvin wrote: > On April 15, 2016 9:10:44 AM PDT, Hubert Kario =20= 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: > >> >=20 > >> > http://lists.gnu.org/archive/html/qemu-devel/2012-09/msg02387.ht= m > >> > l > > > >https://lists.gnu.org/archive/html/qemu-devel/2013-03/threads.html#0= > > > >> > 0023 > >> >=20 > >> > libvirt's rejection of /dev/urandom has generated some complaint= s > >> > from users: > >> >=20 > >> > https://bugzilla.redhat.com/show_bug.cgi?id=3D1074464 > >> > * cited: http://www.2uo.de/myths-about-urandom/ > >> > http://www.redhat.com/archives/libvir-list/2016-March/msg01062.h= t > >> > ml > >> > http://www.redhat.com/archives/libvir-list/2016-April/msg00186.h= t > >> > ml > >> >=20 > >> > I think it's worth having another discussion about this, at leas= t > >> > 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: > >> >=20 > >> > 1) is the original recommendation to never use > >> > virtio-rng+/dev/urandom correct? > >>=20 > >> 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. >=20 > 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=20 Service on your own infrastructure? Besides, what's the difference between spinning a CSPRNG in host rather= =20 that guest? If anything, spinning CSPRNG in host is less of a waste as=20= the virtualisation overhead (however small) isn't there. If you need X=20= number of random bytes, you need to provide X number of random bytes.=20= 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=20 continue generating unpredictable random numbers for years (if not=20 decades or centuries) without any additional entropy. And you certainly= =20 will gather enough entropy to reseed /dev/urandom multiple times an=20 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.= =20 > Of course, none of this matters on newer Intel hardware ;) Not everybody is running on newer Intel, not everybody is even running=20= on x86_64 architecture. Not everybody trusts the RNG in Intel hardware=20= (e.g. rdrand is a not-Approved algorithm for FIPS certified software). =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart1648327.9lYaPWWC1R Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJXFL5GAAoJEJKo0bgB0vX1hXkP/1rg1um6u4ERJLfsV16Mfwh9 yu0VlSwDLvly0/FT9fbicfPvpenvjUzLdOlW916d3KpO51M7vO8UeqKry5uf4nlU 6yyp++LYK3rToTHbO7eDlUcVzWFNsm6Yplh76MzeQwyDlSW/yUZLxqDl0EKtXaSo D5nniySVs6kFCaJrG03daOWmkC3Rimn61z+lV4h1RvVxiVTH35DZJkgkNWHw003Y EAtCwVp87VmzAcEb8Fcl8hrgWvQPhvDJTV8/7+pO6SkmPaWft/Yk2Zfo1OsnKG+c PskC4bsCMyknO+HuOn9UbFYxaiqmbyDbBdDZs5C/y17vUrtO9T5+A2QxZA+hn+q5 RUW2qlh1qWV4kCf0WMwE1fHToKzldMh85DHayBosW52/ElDpzgKa6b1odKYPi61o raPt08ha5DaNdDPVb6dreHT/NV/nsO2XRm6Ith3TBCOLfnmCNZkrBWAQLfHdqyFP CUeKF/GnVCuhOIabvNoYuuWJuo7VR54rciVQ15KRiIqcp7t5T//pIW74fPIzIdri ZQTa+P2yrEAZ2LrXjrT9GXY3ZsZvnIM+h2lqA6auzL2uA6FuRNHuJ2Sj8eSKJkTO oxWyrxI0mWZhbkzNsr2n4xFeR06uIe1t//MuPzAYzuVk6EBeJIdnGNhLe4Fnc26R NqjuJnenEul5WwfRAgFN =bmr7 -----END PGP SIGNATURE----- --nextPart1648327.9lYaPWWC1R--