bcm2835_rng: Use qcrypto_random_bytes() rather than rand()

Message ID 1487334159-19664-1-git-send-email-peter.maydell@linaro.org
State Superseded
Headers show

Commit Message

Peter Maydell Feb. 17, 2017, 12:22 p.m.
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.

 hw/misc/bcm2835_rng.c | 26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

-- 
2.7.4

Comments

Daniel P. Berrange Feb. 17, 2017, 2:05 p.m. | #1
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/ :|
Peter Maydell Feb. 17, 2017, 2:11 p.m. | #2
On 17 February 2017 at 14:05, Daniel P. Berrange <berrange@redhat.com> wrote:
> On Fri, Feb 17, 2017 at 12:22:39PM +0000, Peter Maydell wrote:

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


Ah, and OSX and the BSDs have those devices. (I had
mistakenly assumed they were a linuxism.)

> What would fail, is uses it from a chroot with an empty /dev

> of course.


Yes; replacing the rand() in linux-user/main.c would require
this I think (unless we're willing to fall back to rand ;-))

thanks
-- PMM

Patch

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: