From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
Cc: qemu-devel@nongnu.org, "Richard W.M. Jones" <rjones@redhat.com>,
Laszlo Ersek <lersek@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
Kashyap Chamarthy <kchamart@redhat.com>
Subject: Re: [Qemu-devel] [RFC] Virtio RNG: Consider changing the default entropy source to /dev/urandom?
Date: Tue, 7 May 2019 16:22:11 +0100 [thread overview]
Message-ID: <20190507152211.GU27205@redhat.com> (raw)
In-Reply-To: <CADh2w8TEVZt3KMDiiT8c7Ez+80=gaTB6=8azJQt0Ni58L7e0WQ@mail.gmail.com>
On Tue, May 07, 2019 at 11:59:05AM +0200, Nikos Mavrogiannopoulos wrote:
> In terms of RHEL what is preferred is (1) use a crypto lib, and (2) if
> that's not possible use getrandom(). That is summarized in this
> article:
>
> https://www.redhat.com/en/blog/understanding-red-hat-enterprise-linux-random-number-generator-interface
For QEMU this would mean re-writing the code to use qcrypto_random_bytes
instead. This internal API is backed by a crypto lib if available,
falling back to /dev/urandom or /dev/random on UNIX, or CryptGenRandom
on Windows. We could add getrandom() support there too.
The main question is whether to implement a new backends/rng-builtin.c
or modify backends/rng-random.c so that it has a NULL filename by
default, which would be taken as meaning use the qcrypto_random_bytes
API. The latter benefits that all existing VMs which don't have a
filename set would get the new behaviour. The latter has downside
that it is not discoverable from mgmt apps, so they won't know if
they can rely on it or not.
Thus I'd probably tend towards a new backend for discoverability.
>
> On Thu, May 2, 2019 at 8:02 PM Kashyap Chamarthy <kchamart@redhat.com> wrote:
> >
> > [Reviving this old thread as I don't think we came to a conclusion on
> > this.]
> >
> > On Fri, Sep 21, 2018 at 05:43:23PM +0200, Kashyap Chamarthy wrote:
> > > Hi folks,
> > >
> > > As Markus pointed out in this 'qemu-devel' thread[1],
> > > backends/rng-random.c uses '/dev/random' in TYPE_RNG_RANDOM's
> > > instance_init() method:
> > >
> > > [...]
> > > static void rng_random_init(Object *obj)
> > > {
> > > RngRandom *s = RNG_RANDOM(obj);
> > >
> > > object_property_add_str(obj, "filename",
> > > rng_random_get_filename,
> > > rng_random_set_filename,
> > > NULL);
> > >
> > > s->filename = g_strdup("/dev/random");
> > > s->fd = -1;
> > > }
> > > [...]
> > >
> > > And I've looked at hw/virtio/virtio-rng.c:
> > >
> > > [...]
> > > static void virtio_rng_device_realize(DeviceState *dev, Error **errp)
> > > {
> > > [...]
> > >
> > > if (vrng->conf.rng == NULL) {
> > > vrng->conf.default_backend = RNG_RANDOM(object_new(TYPE_RNG_RANDOM));
> > > [...]
> > >
> > > From the above, I'm assuming QEMU uses `/dev/random` as the _default_
> > > entropy source for a 'virtio-rng-pci' device. If my assumption is
> > > correct, any reason why not to change the default entropy source for
> > > 'virtio-rng-pci' devices to `/dev/urandom` (which is the preferred[2]
> > > source of entropy)?
> > >
> > > And I understand (thanks: Eric Blake for correcting my confusion) that
> > > there are two cases to distinguish:
> > >
> > > (a) When QEMU needs a random number, the entropy source it chooses.
> > > IIUC, the answer is: QEMU defers to GnuTLS by default, which uses
> > > getrandom(2), which in turn uses '/dev/urandom' as its entropy
> > > source; if getrandom(2) isn't available, GnuTLS uses `/dev/urandom`
> > > anyway. (Thanks: Nikos for clarifying this.)
> > >
> > > If QEMU is built with GnuTLS _disabled_, which I'm not sure if any
> > > Linux distribution does, then it uses libgcrypt, which in turn uses
> > > the undesired and legacy `/dev/random` as the default entropy
> > > source.
> > >
> > > (b) When QEMU exposes a Virtio RNG device to the guest, that device
> > > needs a source of entropy, and IIUC, that source needs to be
> > > "non-blocking" (i.e. `/dev/urandom`). However, currently QEMU
> > > defaults to the problematic `/dev/random`.
> > >
> > > I'd like to get some more clarity on case (b).
> > >
> > >
> > > [1] https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg08335.html
> > > -- RNG: Any reason QEMU doesn't default to `/dev/urandom`
> > >
> > > [2] http://man7.org/linux/man-pages/man4/urandom.4.html
> > >
> > >
> > > --
> > > /kashyap
> > >
> >
> > --
> > /kashyap
>
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 :|
next prev parent reply other threads:[~2019-05-07 15:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180921154323.GS28120@paraplu>
2019-05-02 18:02 ` [Qemu-devel] [RFC] Virtio RNG: Consider changing the default entropy source to /dev/urandom? Kashyap Chamarthy
2019-05-02 18:02 ` Kashyap Chamarthy
2019-05-03 7:59 ` Richard W.M. Jones
2019-05-03 7:59 ` Richard W.M. Jones
2019-05-07 9:59 ` Nikos Mavrogiannopoulos
2019-05-07 15:22 ` Daniel P. Berrangé [this message]
2019-05-07 15:53 ` Eric Blake
2019-05-07 17:14 ` Richard Henderson
2019-05-07 17:27 ` Daniel P. Berrangé
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=20190507152211.GU27205@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@redhat.com \
--cc=kchamart@redhat.com \
--cc=lersek@redhat.com \
--cc=nmav@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rjones@redhat.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).