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 <kcham...@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 > > 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 :|