From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Cc: lvivier@redhat.com, qemu-ppc@nongnu.org,
richard.henderson@linaro.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [QEMU] crypto/random: Fall back to /dev/random when getrandom returns EAGAIN
Date: Wed, 17 Jul 2019 08:54:17 +0100 [thread overview]
Message-ID: <20190717075417.GA2891@redhat.com> (raw)
In-Reply-To: <1563346686.2145.11.camel@gmail.com>
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 :|
prev parent reply other threads:[~2019-07-17 7:54 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-17 6:58 [Qemu-devel] [QEMU] crypto/random: Fall back to /dev/random when getrandom returns EAGAIN Suraj Jitindar Singh
2019-07-17 7:54 ` Daniel P. Berrangé [this message]
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=20190717075417.GA2891@redhat.com \
--to=berrange@redhat.com \
--cc=lvivier@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=sjitindarsingh@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).