qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kashyap Chamarthy <kchamart@redhat.com>
To: qemu-devel@nongnu.org
Cc: rjones@redhat.com, dgilbert@redhat.com, berrange@redhat.com
Subject: [Qemu-devel] RNG: Any reason QEMU doesn't default to `/dev/urandom`?
Date: Mon, 25 Jun 2018 12:12:16 +0200	[thread overview]
Message-ID: <20180625101216.GE18277@paraplu> (raw)

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

             reply	other threads:[~2018-06-25 10:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-25 10:12 Kashyap Chamarthy [this message]
2018-06-28 12:15 ` [Qemu-devel] RNG: Any reason QEMU doesn't default to `/dev/urandom`? Markus Armbruster
2018-06-28 12:22   ` Daniel P. Berrangé
2018-06-29 10:08   ` Kashyap Chamarthy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180625101216.GE18277@paraplu \
    --to=kchamart@redhat.com \
    --cc=berrange@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rjones@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).