qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 1/3] VirtIO-RNG: Update default entropy sourc


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH v3 1/3] VirtIO-RNG: Update default entropy source to `/dev/urandom`
Date: Fri, 10 May 2019 12:55:18 -0400

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 <address@hidden>
> > > > > 
> > > > > 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
> 
> Regards,
> Daniel

In particular

https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg02238.html


maybe clarify this is just for systems without getrandom then.




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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]