Message ID | 20190529143106.11789-2-lvivier@redhat.com |
---|---|
State | New |
Headers | show |
Series | rng-builtin: add an RNG backend that uses qemu_guest_getrandom() | expand |
On 29/05/2019 16:31, 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 > 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> > Reviewed-by: Markus Armbruster <armbru@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 39dc17042967..f6e9bd1d9c42 100644 > --- a/qemu-options.hx > +++ b/qemu-options.hx > @@ -4328,7 +4328,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} > > I can push this one via a trivial-branch pull request if no one thinks other patches of the series are ready to be merged. Thanks, Laurent
Le 29/05/2019 à 16:31, Laurent Vivier a écrit : > 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> > Reviewed-by: Markus Armbruster <armbru@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 39dc17042967..f6e9bd1d9c42 100644 > --- a/qemu-options.hx > +++ b/qemu-options.hx > @@ -4328,7 +4328,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} > > As this patch is trivial and reviewed by at least 3 persons, and it seems no one wants to take care of it, I will push it through my next trivial pull request. Thanks, Laurent
On 5/29/19 4:31 PM, 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 > 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> > Reviewed-by: Markus Armbruster <armbru@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 39dc17042967..f6e9bd1d9c42 100644 > --- a/qemu-options.hx > +++ b/qemu-options.hx > @@ -4328,7 +4328,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} > > Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
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 39dc17042967..f6e9bd1d9c42 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -4328,7 +4328,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}