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

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

[Kashyap Chamarthy]

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

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

    - - -

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>
---
v2:
 - Update commit message to mention justification for preferring
   `/dev/urandom` over `/dev/random` [stefanha]
---
 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 e2a49b0571d79eab335d5a74841d92c50a727b6a..eff36ef14084bccaad1eabe952e2cf6ffa9a2529 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 51802cbb266a208d70989c4f0ab3317a76edc1ea..a525609149e4d0e4bb60959f029a1a16eb36900d 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -4276,7 +4276,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.17.2

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

[Kashyap Chamarthy]

On Fri, May 10, 2019 at 10:15:25AM +0200, Kashyap Chamarthy wrote:

[...]

> Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>

I didn't intentionally retain Dan and Rich's "Reviewed-by" tags.  Maybe
I should have, because I only updated the commit message.

> ---
> v2:
>  - Update commit message to mention justification for preferring
>    `/dev/urandom` over `/dev/random` [stefanha]
> ---
>  backends/rng-random.c | 2 +-
>  qemu-options.hx       | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

[...]

-- 
/kashyap

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

[Daniel P. Berrangé]

On Fri, May 10, 2019 at 10:15:25AM +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).
> 
> 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`.
> 
>     - - -
> 
> 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>
> ---
> v2:
>  - Update commit message to mention justification for preferring
>    `/dev/urandom` over `/dev/random` [stefanha]
> ---
>  backends/rng-random.c | 2 +-
>  qemu-options.hx       | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 3018 bytes --]

On Fri, May 10, 2019 at 10:15:25AM +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).
> 
> 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`.
> 
>     - - -
> 
> 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>
> ---
> v2:
>  - Update commit message to mention justification for preferring
>    `/dev/urandom` over `/dev/random` [stefanha]
> ---
>  backends/rng-random.c | 2 +-
>  qemu-options.hx       | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Markus Armbruster]

Kashyap Chamarthy <kchamart@redhat.com> writes:

> 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).
>
> 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`.

This is Linux.  What about other supported POSIX[*] hosts?  If any such
host has /dev/random that works here, but not /dev/urandom, we regress.

*If* there's an actual regression risk: a simple & stupid way to reduce
it risk could be falling back to /dev/random when opening /dev/urandom
fails.  Perhaps only when it fails with ENOENT.

Possible implementation: instead of setting a default filename in
rng_random_init(), change rng_random_opened() to try /dev/urandom, then
/dev/random when filename is still null.

Aside: "opened" sounds like a predicate.  Goes back to commit
a9b7b2ad7b0.

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

[*] POSIX because
common-obj-$(CONFIG_POSIX) += rng-random.o

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

[Daniel P. Berrangé]

On Fri, May 10, 2019 at 02:03:33PM +0200, Markus Armbruster wrote:
> Kashyap Chamarthy <kchamart@redhat.com> writes:
> 
> > 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).
> >
> > 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`.
> 
> This is Linux.  What about other supported POSIX[*] hosts?  If any such
> host has /dev/random that works here, but not /dev/urandom, we regress.

It exists on OS-X, FreeBSD, DragonFlyBSD, NetBSD and OpenBSD, which covers
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
by default, as that will work on Windows.

> *If* there's an actual regression risk: a simple & stupid way to reduce
> it risk could be falling back to /dev/random when opening /dev/urandom
> fails.  Perhaps only when it fails with ENOENT.

Unless I missed something, I think we'll be ok without the fallback
though I wouldn't object to having a fallback as you describe.

> Possible implementation: instead of setting a default filename in
> rng_random_init(), change rng_random_opened() to try /dev/urandom, then
> /dev/random when filename is still null.
> 
> Aside: "opened" sounds like a predicate.  Goes back to commit
> a9b7b2ad7b0.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|