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