Message ID | 20190510134203.24012-2-lvivier@redhat.com |
---|---|
State | New |
Headers | show |
Series | rng-builtin: add an RNG backend thatuses qemu_guest_getrandom() | expand |
On Fri, May 10, 2019 at 03:42:01PM +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 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. So how about just using getrandom then? > > "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> > 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
On Fri, May 10, 2019 at 12:12:41PM -0400, Michael S. Tsirkin wrote: > On Fri, May 10, 2019 at 03:42:01PM +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 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. > > So how about just using getrandom then? The 3rd patch in this series addresses that. Regards, Daniel
On Fri, May 10, 2019 at 05:16:44PM +0100, Daniel P. Berrangé wrote: > On Fri, May 10, 2019 at 12:12:41PM -0400, Michael S. Tsirkin wrote: > > On Fri, May 10, 2019 at 03:42:01PM +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 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. > > > > So how about just using getrandom then? > > The 3rd patch in this series addresses that. It seems to use qemu_guest_getrandom which in turn with patch 1 calls /dev/urandom... Did I miss something? > > 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 :|
On Fri, May 10, 2019 at 12:21:19PM -0400, Michael S. Tsirkin wrote: > On Fri, May 10, 2019 at 05:16:44PM +0100, Daniel P. Berrangé wrote: > > On Fri, May 10, 2019 at 12:12:41PM -0400, Michael S. Tsirkin wrote: > > > On Fri, May 10, 2019 at 03:42:01PM +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 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. > > > > > > So how about just using getrandom then? > > > > The 3rd patch in this series addresses that. > > It seems to use qemu_guest_getrandom which in turn > with patch 1 calls /dev/urandom... > Did I miss something? qemu_guest_getrandom will preferentially use the crypto library random APIs (gnutls, or gcrypt). If both are compiled out that it will use getrandom() if supported by the C library and current kernel. If that fails then it will try /dev/urandom if it exists, finally /dev/random. On Windows it uses their native crypto API. See this dependant series: https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg02237.html Regards, Daniel
On Fri, May 10, 2019 at 05:25:54PM +0100, Daniel P. Berrangé wrote: > On Fri, May 10, 2019 at 12:21:19PM -0400, Michael S. Tsirkin wrote: > > On Fri, May 10, 2019 at 05:16:44PM +0100, Daniel P. Berrangé wrote: > > > On Fri, May 10, 2019 at 12:12:41PM -0400, Michael S. Tsirkin wrote: > > > > On Fri, May 10, 2019 at 03:42:01PM +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 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. > > > > > > > > So how about just using getrandom then? > > > > > > The 3rd patch in this series addresses that. > > > > It seems to use qemu_guest_getrandom which in turn > > with patch 1 calls /dev/urandom... > > Did I miss something? > > qemu_guest_getrandom will preferentially use the crypto library random > APIs (gnutls, or gcrypt). If both are compiled out that it will use > getrandom() if supported by the C library and current kernel. If that > fails then it will try /dev/urandom if it exists, finally /dev/random. > On Windows it uses their native crypto API. See this dependant series: > > https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg02237.html > > Regards, > Daniel In particular https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg02238.html maybe clarify this is just for systems without getrandom then. > -- > |: 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 :|
On Fri, May 10, 2019 at 12:55:18PM -0400, Michael S. Tsirkin wrote: > On Fri, May 10, 2019 at 05:25:54PM +0100, Daniel P. Berrangé wrote: > > On Fri, May 10, 2019 at 12:21:19PM -0400, Michael S. Tsirkin wrote: > > > On Fri, May 10, 2019 at 05:16:44PM +0100, Daniel P. Berrangé wrote: > > > > On Fri, May 10, 2019 at 12:12:41PM -0400, Michael S. Tsirkin wrote: > > > > > On Fri, May 10, 2019 at 03:42:01PM +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 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. > > > > > > > > > > So how about just using getrandom then? > > > > > > > > The 3rd patch in this series addresses that. > > > > > > It seems to use qemu_guest_getrandom which in turn > > > with patch 1 calls /dev/urandom... > > > Did I miss something? > > > > qemu_guest_getrandom will preferentially use the crypto library random > > APIs (gnutls, or gcrypt). If both are compiled out that it will use > > getrandom() if supported by the C library and current kernel. If that > > fails then it will try /dev/urandom if it exists, finally /dev/random. > > On Windows it uses their native crypto API. See this dependant series: > > > > https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg02237.html > > In particular > > https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg02238.html > > maybe clarify this is just for systems without getrandom then. I'm not sure I see what the problem is. That patch is implementing the fallback behaviour I describe above, with the crypto library preferred, falling back to getrandom, then /dev/urandom, finally /dev/random. Regards, Daniel
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}