From: Kashyap Chamarthy <kchamart@redhat.com>
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 on linux is "blocking" (as in, it waits until
sufficient entropy is available).
Why prefer `/dev/urandom` over `/dev/random`?
---------------------------------------------
The man pages of urandom(4) and random(4) state:
"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."
Further, the "Usage" section of the said man pages state:
"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 immediately
available."
And refer to random(7) for a comparison of `/dev/random` and
`/dev/urandom`.
What about other OSes?
----------------------
`/dev/urandom` exists and works on OS-X, FreeBSD, DragonFlyBSD, NetBSD
and OpenBSD, which cover all the non-Linux platforms we explicitly
support, aside from Windows.
On Windows `/dev/random` doesn't work either so we don't regress.
This is actually another argument in favour of using the newly
proposed 'rng-builtin' backend by default, as that will work on
Windows.
- - -
Given the above, change the entropy source for VirtIO-RNG device to
`/dev/urandom`.
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"
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
---
backends/rng-random.c | 2 +-
qemu-options.hx | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/backends/rng-random.c b/backends/rng-random.c
index e2a49b0571d7..eff36ef14084 100644
--- a/backends/rng-random.c
+++ b/backends/rng-random.c
@@ -112,7 +112,7 @@ static void rng_random_init(Object *obj)
rng_random_set_filename,
NULL);
- s->filename = g_strdup("/dev/random");
+ s->filename = g_strdup("/dev/urandom");
s->fd = -1;
}
diff --git a/qemu-options.hx b/qemu-options.hx
index 0191ef8b1eb7..4df0ea3aed5c 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -4286,7 +4286,7 @@ Creates a random number generator backend which obtains entropy from
a device on the host. The @option{id} parameter is a unique ID that
will be used to reference this entropy backend from the @option{virtio-rng}
device. The @option{filename} parameter specifies which file to obtain
-entropy from and if omitted defaults to @option{/dev/random}.
+entropy from and if omitted defaults to @option{/dev/urandom}.
@item -object rng-egd,id=@var{id},chardev=@var{chardevid}
--
2.20.1
Laurent Vivier <lvivier@redhat.com> writes: > From: Kashyap Chamarthy <kchamart@redhat.com> > > 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 on linux is "blocking" (as in, it waits until > sufficient entropy is available). > > Why prefer `/dev/urandom` over `/dev/random`? > --------------------------------------------- > > The man pages of urandom(4) and random(4) state: > > "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." > > Further, the "Usage" section of the said man pages state: > > "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 immediately > available." > > And refer to random(7) for a comparison of `/dev/random` and > `/dev/urandom`. > > What about other OSes? > ---------------------- > > `/dev/urandom` exists and works on OS-X, FreeBSD, DragonFlyBSD, NetBSD > and OpenBSD, which cover all the non-Linux platforms we explicitly > support, aside from Windows. > > On Windows `/dev/random` doesn't work either so we don't regress. > This is actually another argument in favour of using the newly > proposed 'rng-builtin' backend by default, as that will work on > Windows. > > - - - > > Given the above, change the entropy source for VirtIO-RNG device to > `/dev/urandom`. > > 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" > > Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com> > Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> > Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> > Signed-off-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com>
On Tue, May 14, 2019 at 09:56:00AM +0200, Laurent Vivier wrote: > From: Kashyap Chamarthy <kchamart@redhat.com> > > 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 on linux is "blocking" (as in, it waits until OCD nit: s/linux/Linux/ Maybe Michael can do the touch up when applying. Thanks, Laurent, for reworking the commit message update. > sufficient entropy is available). [...] -- /kashyap
On 14/05/2019 10:08, Kashyap Chamarthy wrote: > On Tue, May 14, 2019 at 09:56:00AM +0200, Laurent Vivier wrote: >> From: Kashyap Chamarthy <kchamart@redhat.com> >> >> 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 on linux is "blocking" (as in, it waits until > > OCD nit: s/linux/Linux/ > > Maybe Michael can do the touch up when applying. A little reminder: this patch can be applied alone, but the followings need the series from Richard to be applied first. Thanks, Laurent
Laurent Vivier <lvivier@redhat.com> writes:
> On 14/05/2019 10:08, Kashyap Chamarthy wrote:
>> On Tue, May 14, 2019 at 09:56:00AM +0200, Laurent Vivier wrote:
>>> From: Kashyap Chamarthy <kchamart@redhat.com>
>>>
>>> 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 on linux is "blocking" (as in, it waits until
>>
>> OCD nit: s/linux/Linux/
>>
>> Maybe Michael can do the touch up when applying.
>
> A little reminder: this patch can be applied alone, but the followings
> need the series from Richard to be applied first.
I guess you mean
[PATCH v6 00/25] Add qemu_getrandom and ARMv8.5-RNG etc
Message-Id: <20190510173049.28171-1-richard.henderson@linaro.org>
You can make the dependency machine-readable by declaring
Based-on: <20190510173049.28171-1-richard.henderson@linaro.org>
in your cover letter. Patchew will then test your series on top of
Richard's.
© 2016 - 2026 Red Hat, Inc.