Re: [Qemu-devel] [PATCH v3 1/3] VirtIO-RNG: Update default entropy source to `/dev/urandom`

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, May 10, 2019 at 12:55:18PM -0400, Michael S. Tsirkin wrote:
> On Fri, May 10, 2019 at 05:25:54PM +0100, Daniel P. Berrangé wrote:
> > On Fri, May 10, 2019 at 12:21:19PM -0400, Michael S. Tsirkin wrote:
> > > On Fri, May 10, 2019 at 05:16:44PM +0100, Daniel P. Berrangé wrote:
> > > > On Fri, May 10, 2019 at 12:12:41PM -0400, Michael S. Tsirkin wrote:
> > > > > On Fri, May 10, 2019 at 03:42:01PM +0200, Laurent Vivier wrote:
> > > > > > From: Kashyap Chamarthy <kchamart@redhat.com>
> > > > > > 
> > > > > > When QEMU exposes a VirtIO-RNG device to the guest, that device needs a
> > > > > > source of entropy, and that source needs to be "non-blocking", like
> > > > > > `/dev/urandom`.  However, currently QEMU defaults to the problematic
> > > > > > `/dev/random`, which is "blocking" (as in, it waits until sufficient
> > > > > > entropy is available).
> > > > > > 
> > > > > > Why prefer `/dev/urandom` over `/dev/random`?
> > > > > > ---------------------------------------------
> > > > > > 
> > > > > > The man pages of urandom(4) and random(4) state:
> > > > > > 
> > > > > >     "The /dev/random device is a legacy interface which dates back to a
> > > > > >     time where the cryptographic primitives used in the implementation
> > > > > >     of /dev/urandom were not widely trusted.  It will return random
> > > > > >     bytes only within the estimated number of bits of fresh noise in the
> > > > > >     entropy pool, blocking if necessary.  /dev/random is suitable for
> > > > > >     applications that need high quality randomness, and can afford
> > > > > >     indeterminate delays."
> > > > > > 
> > > > > > Further, the "Usage" section of the said man pages state:
> > > > > > 
> > > > > >     "The /dev/random interface is considered a legacy interface, and
> > > > > >     /dev/urandom is preferred and sufficient in all use cases, with the
> > > > > >     exception of applications which require randomness during early boot
> > > > > >     time; for these applications, getrandom(2) must be used instead,
> > > > > >     because it will block until the entropy pool is initialized.
> > > > > 
> > > > > So how about just using getrandom then?
> > > > 
> > > > The 3rd patch in this series addresses that.
> > > 
> > > It seems to use qemu_guest_getrandom which in turn
> > > with patch 1 calls /dev/urandom...
> > > Did I miss something?
> > 
> > qemu_guest_getrandom will preferentially use the crypto library random
> > APIs (gnutls, or gcrypt). If both are compiled out that it will use
> > getrandom() if supported by the C library and current kernel. If that
> > fails then it will try /dev/urandom if it exists, finally /dev/random. 
> > On Windows it uses their native crypto API. See this dependant series:
> > 
> > https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg02237.html
> 
> In particular
> 
> https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg02238.html
> 
> maybe clarify this is just for systems without getrandom then.

I'm not sure I see what the problem is. That patch is implementing the
fallback behaviour I describe above, with the crypto library preferred,
falling back to getrandom, then /dev/urandom, finally /dev/random.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|