[Qemu-devel] [QEMU] crypto/random: Fall back to /dev/random when getrandom returns EAGAIN

[Qemu-devel] [QEMU] crypto/random: Fall back to /dev/random when getrandom returns EAGAIN

[Suraj Jitindar Singh]

Hi,

I'm trying to use qemu inside a a guest, however since there isn't
enough entropy for the rng getrandom() blocks. This means I am unable
to even get output from 'qemu --help' for example. This is annoying at
best.

Thinking about ways to work around this obviously the major one is to
have an entropy source for the guest.

In cases where this isn't possible I think it would make sense to fall
back to the old /dev/random source when the getrandom() syscall returns
EAGAIN indicating that it would block.

Alternatively it would be nice to have a config option to disable the
new getrandom interface, along the lines of --disable-getrandom.

If you feel that either of the approaches would be statisfactory I'd be
happy to send a patch. Otherwise if we can have a discussion here with
regards to how to progress.

Kind Regards,
Suraj

Re: [Qemu-devel] [QEMU] crypto/random: Fall back to /dev/random when getrandom returns EAGAIN

[Daniel P. Berrangé]

On Wed, Jul 17, 2019 at 04:58:06PM +1000, Suraj Jitindar Singh wrote:
> Hi,
> 
> I'm trying to use qemu inside a a guest, however since there isn't
> enough entropy for the rng getrandom() blocks. This means I am unable
> to even get output from 'qemu --help' for example. This is annoying at
> best.

Are you running QEMU during early boot ? Normally when there are
problems with the urandom source not being initialized, some OS
process will hang during early boot waiting for entropy. 

> Thinking about ways to work around this obviously the major one is to
> have an entropy source for the guest.

Yes, this is the strongly preferred solution. It is nice if the guest
can be provided a virtio-rng device, but that's not the only option.
The Linux kernel has a jitterentropy source which generates random
numbers from CPU jitter which should work in all cases if nothing
else is available as a random data source.

> In cases where this isn't possible I think it would make sense to fall
> back to the old /dev/random source when the getrandom() syscall returns
> EAGAIN indicating that it would block.

QEMU calls getrandom() with flags==0 and thus the data it is requesting
comes from the urandom source.  This should only block during early
boot when the kernel RNG source has not been initialized.

In this case falling back to /dev/random will also certainly block.
Perhaps that was a typo and you meant to fallback to /dev/urandom.
This would indeed not block, because the data it returns will *not*
be considered random due to urandom source not being initialized
yet. I think it would be a bad idea for QEMU to use this non-random
data.

> Alternatively it would be nice to have a config option to disable the
> new getrandom interface, along the lines of --disable-getrandom.

Disabling would have the same effect - if the urandom pool is not
initialized yet, QEMU would be reading data that is not random.

> If you feel that either of the approaches would be statisfactory I'd be
> happy to send a patch. Otherwise if we can have a discussion here with
> regards to how to progress.

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