[Top][All Lists]

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

[Qemu-devel] RNG: Any reason QEMU doesn't default to `/dev/urandom`?

From: Kashyap Chamarthy
Subject: [Qemu-devel] RNG: Any reason QEMU doesn't default to `/dev/urandom`?
Date: Mon, 25 Jun 2018 12:12:16 +0200
User-agent: Mutt/1.9.2 (2017-12-15)

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

`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

       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:


reply via email to

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