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[*]:
[quote]
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.
[/quote]
(2) The man pages of `random(4) and `urandom(4)`:
Both the man pages say 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 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
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."
(3) And this widely-referred document (by Thomas Hühn, who describes
himself as "interested in ... Cryptography, standing on the
sidelines"):
"Myths about /dev/urandom"
https://www.2uo.de/myths-about-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
--
/kashyap
