[Top][All Lists]

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

Re: [Qemu-devel] [PATCH] VirtIO-RNG: Update default entropy source to `/

From: Kashyap Chamarthy
Subject: Re: [Qemu-devel] [PATCH] VirtIO-RNG: Update default entropy source to `/dev/urandom`
Date: Thu, 9 May 2019 17:59:58 +0200
User-agent: Mutt/1.11.3 (2019-02-01)

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"?

Allow me to quote three expert sources.

(1) Let's start with Ted Ts'o, who is the author of the /dev/random.
    So it's as authoritative as it gets.  Ted Ts'o writes[*]:

      My recommendation is to just seed virtio-rng from /dev/urandom.
      Here's why.  /dev/urandom provides a cryptographic random number
      generator, and assuming it is adequately initialized, that should be
      *fine* for pretty much all practical purposes.  And on the sort of
      systems you would be using as a Host, there are enough hardware
      devices that /dev/urandom will be initialized very quickly --- in
      practice, well before any VM's will be started.
      Furthermore, all modern x86 systems have RDRAND by now, and on those
      systems, the host kernel will mix RDRAND output with CRNG before
      sending the random numbers out via getrandom(2) or /dev/urandom.
      From a guest perspective, you have to trust the Host system anyway.
      The host as the ability to read or modify arbitrary guest memory,
      including that used by the kernel.  The host can mess with the guest
      kernel before it's booted, or change the contents of the emulated hard
      drive.  So trusting that the host CPU has implemented RDRAND correctly
      isn't a stretch.  So even if the customer running the VM is a
      tin-foil-hatter who believes the NSA may have backdoored RDRAND and
      not have it be discovered or leaked out, in most cases, they aren't
      the sort of people who would want to use a cloud infrastructure.
      They're much more likely to want to use hardware which always stays
      under their personal control.
      And even if you *do* believe the NSA has somehow managed to sneak a
      backdoor into Intel CPU designs without it become public, that still
      means that you have to break the CRNG.  And practically speaking,
      assuming it's been initialized correctly, if you can break the CRNG,
      we've got much bigger problems, since that implies you can't trust the
      basic crypto primitives we use to secure our entire internet. 

(2) The man pages of `random(4) and `urandom(4)`:

    Both the man pages say the following about the blocking nature of

       "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 their the "Usage" section:

       "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

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

(3) And this widely-referred document (by Thomas Hühn, who describes
    himself as "interested in ... Cryptography, standing on the

      "Myths about /dev/urandom"

    I'm not going to quote the relevant parts, but the document is
    competently written, and is well worth reading.

> I understand the requirement for instant random numbers, but what
> about the concerns about quality?  

I'm not a Crypto or RNG expert, but what precise "concerns" are these?
>From my reading on this topic over the past several months, there are
some "sticky myths" in this area that Crypto / RNG experts have been
trying to debunk.  Refer to the earlier mentioned sources.

> Have you decided that the consumers of these random numbers are safe
> with /dev/urandom?

I didn't unilaterally decide it, but am relying on the expert sources
that I mentioned earlier.

In all likelihood you know this, but just as a refresher, there are
_two_ cases to distinguish w.r.t random numbers in QEMU:

  (a) When QEMU needs a random number, the entropy source it chooses.
      IIUC, here QEMU defers to GnuTLS, which uses getrandom(2), which
      in turn uses '/dev/urandom' as its entropy source; if getrandom(2)
      isn't available, GnuTLS uses `/dev/urandom` anyway.
  (b) When QEMU exposes a VirtIO-RNG device to the guest, the entropy
  source of that device.

This patch is changing the default of case (b).

> > Related discussion in these[1][2] past threads.
> > 
> > [1] https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg08335.html
> >     -- "RNG: Any reason QEMU doesn't default to `/dev/urandom`?"
> > [2] https://lists.nongnu.org/archive/html/qemu-devel/2018-09/msg02724.html
> >     -- "[RFC] Virtio RNG: Consider changing the default entropy source to
> >        /dev/urandom"
> Please include actual justification in the commit description instead of
> linking to email threads that need to be read and interpreted.

Sure, will do.  I normally bear that in mind, but missed to do it here.
I'll send a v2 by quoting the relevant parts from the
random(4)|urandom(4) man pages.

[*] http://lists.katacontainers.io/pipermail/kata-dev/2018-September/000459.html
    [kata-dev] /dev/urandom or /dev/random


reply via email to

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