On Thu, May 09, 2019 at 02:53:20PM +0100, Stefan Hajnoczi wrote:
> On Fri, May 03, 2019 at 05:46:12PM +0200, Kashyap Chamarthy wrote:
> > 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).
> >
> > So change the entropy source to the recommended `/dev/urandom`.
>
> Why is /dev/urandom "recommended"?
>
> I understand the requirement for instant random numbers, but what about
> the concerns about quality? Have you decided that the consumers of
> these random numbers are safe with /dev/urandom?
The current random(4) man page says:
The /dev/random interface is considered a legacy inter‐
face, 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 ini‐
tialized.
"early boot" is a bit of an ill-defined term here, but I think in
general QEMU can reasonably be said to not be running in early boot.
In any case the newly proposed RNG backend should ultimately become
the preferred choice for mgmt apps:
https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg02062.html
This new rng-builtin delegates to our crypto random APIs, which are
backed by GNUTLS, libgcrypt, getrandom (or Windows equiv), and
finally /dev/urandom as last ditch effort.
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 :|
