From: "Daniel P. Berrange" <berrange@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-arm@nongnu.org, qemu-devel@nongnu.org, patches@linaro.org,
"Marcin Chojnacki" <marcinch7@gmail.com>,
"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [PATCH] bcm2835_rng: Use qcrypto_random_bytes() rather than rand()
Date: Fri, 17 Feb 2017 14:05:05 +0000 [thread overview]
Message-ID: <20170217140505.GB11399@redhat.com> (raw)
In-Reply-To: <1487334159-19664-1-git-send-email-peter.maydell@linaro.org>
On Fri, Feb 17, 2017 at 12:22:39PM +0000, Peter Maydell wrote:
> Switch to using qcrypto_random_bytes() rather than rand() as
> our source of randomness for the BCM2835 RNG.
>
> If qcrypto_random_bytes() fails, we don't want to return the guest a
> non-random value in case they're really using it for cryptographic
> purposes, so the best we can do is a fatal error. This shouldn't
> happen unless something's broken, though.
>
> In theory we could implement this device's full FIFO and interrupt
> semantics and then just stop filling the FIFO. That's a lot of work,
> though, and doesn't really give a very nice diagnostic to the user
> since the guest will just seem to hang.
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> This patch sits on top of http://patchwork.ozlabs.org/patch/726744/
> (though for review purposes I think it's pretty self explanatory).
> The interesting question here is the failure case handling, where
> we're a bit between a rock and a hard place because we don't have
> a nice way to report it to the guest, but we don't want to return
> a non-random value either...
>
> We should probably improve crypto/random-platform.c to use
> getentropy() if available, which would fix the "BSD or OSX
> host and not using gcrypt or gnutls" case which I think is
> the most likely cause of qcrypto_random_bytes() failing.
randopm-platform.c currentl uses /dev/urandom or /dev/random,
so that should work when GNUTLS/gcrypt are both disabled at
build time.
What would fail, is uses it from a chroot with an empty /dev
of course.
So we should definitely try getentropy/getrandom as a preferred
approach, falling back to /dev nodes only if those syscalls don't
exist in the current kenrel. Looks like I already put a TODO
comment in the file to this effect.
>
> hw/misc/bcm2835_rng.c | 26 +++++++++++++++++++++++++-
> 1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/hw/misc/bcm2835_rng.c b/hw/misc/bcm2835_rng.c
> index 2242bc5..bbe903d 100644
> --- a/hw/misc/bcm2835_rng.c
> +++ b/hw/misc/bcm2835_rng.c
> @@ -9,8 +9,32 @@
>
> #include "qemu/osdep.h"
> #include "qemu/log.h"
> +#include "qapi/error.h"
> +#include "crypto/random.h"
> #include "hw/misc/bcm2835_rng.h"
>
> +static uint32_t get_random_bytes(void)
> +{
> + uint32_t res;
> + Error *err = NULL;
> +
> + if (qcrypto_random_bytes((uint8_t *)&res, sizeof(res), &err) < 0) {
> + /* On failure we don't want to return the guest a non-random
> + * value in case they're really using it for cryptographic
> + * purposes, so the best we can do is die here.
> + * This shouldn't happen unless something's broken.
> + * In theory we could implement this device's full FIFO
> + * and interrupt semantics and then just stop filling the
> + * FIFO. That's a lot of work, though, so we assume any
> + * errors are systematic problems and trust that the check
> + * on init is sufficient.
> + */
> + error_report_err(err);
> + exit(1);
> + }
> + return res;
> +}
> +
> static uint64_t bcm2835_rng_read(void *opaque, hwaddr offset,
> unsigned size)
> {
> @@ -27,7 +51,7 @@ static uint64_t bcm2835_rng_read(void *opaque, hwaddr offset,
> res = s->rng_status | (1 << 24);
> break;
> case 0x8: /* rng_data */
> - res = rand();
> + res = get_random_bytes();
> break;
>
> default:
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
WARNING: multiple messages have this Message-ID (diff)
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-arm@nongnu.org, qemu-devel@nongnu.org, patches@linaro.org,
"Marcin Chojnacki" <marcinch7@gmail.com>,
"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [Qemu-devel] [PATCH] bcm2835_rng: Use qcrypto_random_bytes() rather than rand()
Date: Fri, 17 Feb 2017 14:05:05 +0000 [thread overview]
Message-ID: <20170217140505.GB11399@redhat.com> (raw)
In-Reply-To: <1487334159-19664-1-git-send-email-peter.maydell@linaro.org>
On Fri, Feb 17, 2017 at 12:22:39PM +0000, Peter Maydell wrote:
> Switch to using qcrypto_random_bytes() rather than rand() as
> our source of randomness for the BCM2835 RNG.
>
> If qcrypto_random_bytes() fails, we don't want to return the guest a
> non-random value in case they're really using it for cryptographic
> purposes, so the best we can do is a fatal error. This shouldn't
> happen unless something's broken, though.
>
> In theory we could implement this device's full FIFO and interrupt
> semantics and then just stop filling the FIFO. That's a lot of work,
> though, and doesn't really give a very nice diagnostic to the user
> since the guest will just seem to hang.
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> This patch sits on top of http://patchwork.ozlabs.org/patch/726744/
> (though for review purposes I think it's pretty self explanatory).
> The interesting question here is the failure case handling, where
> we're a bit between a rock and a hard place because we don't have
> a nice way to report it to the guest, but we don't want to return
> a non-random value either...
>
> We should probably improve crypto/random-platform.c to use
> getentropy() if available, which would fix the "BSD or OSX
> host and not using gcrypt or gnutls" case which I think is
> the most likely cause of qcrypto_random_bytes() failing.
randopm-platform.c currentl uses /dev/urandom or /dev/random,
so that should work when GNUTLS/gcrypt are both disabled at
build time.
What would fail, is uses it from a chroot with an empty /dev
of course.
So we should definitely try getentropy/getrandom as a preferred
approach, falling back to /dev nodes only if those syscalls don't
exist in the current kenrel. Looks like I already put a TODO
comment in the file to this effect.
>
> hw/misc/bcm2835_rng.c | 26 +++++++++++++++++++++++++-
> 1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/hw/misc/bcm2835_rng.c b/hw/misc/bcm2835_rng.c
> index 2242bc5..bbe903d 100644
> --- a/hw/misc/bcm2835_rng.c
> +++ b/hw/misc/bcm2835_rng.c
> @@ -9,8 +9,32 @@
>
> #include "qemu/osdep.h"
> #include "qemu/log.h"
> +#include "qapi/error.h"
> +#include "crypto/random.h"
> #include "hw/misc/bcm2835_rng.h"
>
> +static uint32_t get_random_bytes(void)
> +{
> + uint32_t res;
> + Error *err = NULL;
> +
> + if (qcrypto_random_bytes((uint8_t *)&res, sizeof(res), &err) < 0) {
> + /* On failure we don't want to return the guest a non-random
> + * value in case they're really using it for cryptographic
> + * purposes, so the best we can do is die here.
> + * This shouldn't happen unless something's broken.
> + * In theory we could implement this device's full FIFO
> + * and interrupt semantics and then just stop filling the
> + * FIFO. That's a lot of work, though, so we assume any
> + * errors are systematic problems and trust that the check
> + * on init is sufficient.
> + */
> + error_report_err(err);
> + exit(1);
> + }
> + return res;
> +}
> +
> static uint64_t bcm2835_rng_read(void *opaque, hwaddr offset,
> unsigned size)
> {
> @@ -27,7 +51,7 @@ static uint64_t bcm2835_rng_read(void *opaque, hwaddr offset,
> res = s->rng_status | (1 << 24);
> break;
> case 0x8: /* rng_data */
> - res = rand();
> + res = get_random_bytes();
> break;
>
> default:
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
next prev parent reply other threads:[~2017-02-17 14:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-17 12:22 [PATCH] bcm2835_rng: Use qcrypto_random_bytes() rather than rand() Peter Maydell
2017-02-17 12:22 ` [Qemu-devel] " Peter Maydell
2017-02-17 14:05 ` Daniel P. Berrange [this message]
2017-02-17 14:05 ` Daniel P. Berrange
2017-02-17 14:11 ` Peter Maydell
2017-02-17 14:11 ` [Qemu-devel] " Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170217140505.GB11399@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=marcinch7@gmail.com \
--cc=patches@linaro.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.