| Message ID | 1487334159-19664-1-git-send-email-peter.maydell@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
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/ :|
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
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:
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