QEMU still defaults to /dev/random as entropy source. Any reason why
not default to /dev/urandom?
The other day Dan Berrangé explained elsewhere that /dev/urandom is
recommended -- as it is non-blocking; and doesn't have the same
limitations of /dev/random, which is a legacy interface. (And other
applications[*] are any way overriding the QEMU default to
/dev/urandom.)
`random(4)` says the following about the blocking nature of /dev/random:
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.
And its "Usage" section says:
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 ran‐ domness during
early boot time; for these applications, getrandom(2) must be
used instead, because it will block until the entropy pool is
initialized.
If a seed file is saved across reboots as recommended below (all
major Linux distributions have done this since 2000 at least),
the output is cryptographically secure against attackers
without local root access as soon as it is reloaded in the boot
sequence, and perfectly adequate for network encryption session
keys. Since reads from /dev/random may block, users will usually
want to open it in nonblocking mode (or perform a read with
timeout), and provide some sort of user notification if the
desired entropy is not immedi‐ ately available.
[*] E.g. libguestfs:
https://github.com/libguestfs/libguestfs/blob/master/lib/launch-direct.c#L592
--
/kashyap
