qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] bcm2835_rng: Use qcrypto_random_bytes() rather


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH] bcm2835_rng: Use qcrypto_random_bytes() rather than rand()
Date: Fri, 17 Feb 2017 14:05:05 +0000
User-agent: Mutt/1.7.1 (2016-10-04)

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 <address@hidden>
> ---
> 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 <address@hidden>

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]