From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Cristian Rodríguez" <cristian@rodriguez.im>
Cc: "open list:All patches CC here" <qemu-devel@nongnu.org>
Subject: Re: [PATCH] crypto/gcrypt: prefer kernel as direct source of entropy
Date: Mon, 22 Jan 2024 14:48:12 +0000 [thread overview]
Message-ID: <Za6ALDkMyW9Pdspd@redhat.com> (raw)
In-Reply-To: <20240119203950.6434-1-cristian@rodriguez.im>
On Fri, Jan 19, 2024 at 05:39:40PM -0300, Cristian Rodríguez wrote:
> gcrypt by default uses an userspace RNG, which cannot know
> when it is time to discard/invalidate its buffer
> (suspend, resume, vm forks, other corner cases)
> as a "when to discard" event is unavailable to userspace.
So in this scenario QEMU is impacted when QEMU is running inside
another VM. ie the L0 QEMU "forks" the guest, and the L1 QEMU
needs to re-init its RNG.
> Set GCRYCTL_SET_PREFERRED_RNG_TYPE to GCRY_RNG_TYPE_SYSTEM
> which must be done before the first call to gcry_check_version()
QEMU is just one out of many applications that use libgcrypt and
I see no reason why QEMU should be special cased in this respect.
Updating each application to hardcode use of GCRY_RNG_TYPE_SYSTEM
does not feel like a good solution. If this was a good default
to use everywhere, then gcrypt should have set this default
already, rather than requiring every app to solve the forking
problem itself.
Updating every app that uses gcrypt is not really practical
in terms of time investment anyway.
If gcrypt doesn't want to make this its global default, then
I would suggest that gcrypt should make its default be
configurable. I see from its docs:
https://gnupg.org/documentation/manuals/gcrypt/Configuration.html#Configuration
that it already supports a /etc/gcrypt/random.conf file.
Perhaps they would extend that to allow selection of the
default RNG backend, system-wide.
>
> Signed-off-by: Cristian Rodríguez <cristian@rodriguez.im>
> ---
> crypto/init.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/crypto/init.c b/crypto/init.c
> index fb7f1bff10..0c3fe6a841 100644
> --- a/crypto/init.c
> +++ b/crypto/init.c
> @@ -60,6 +60,7 @@ int qcrypto_init(Error **errp)
> #endif
>
> #ifdef CONFIG_GCRYPT
> + gcry_control(GCRYCTL_SET_PREFERRED_RNG_TYPE, GCRY_RNG_TYPE_SYSTEM);
> if (!gcry_check_version(NULL)) {
> error_setg(errp, "Unable to initialize gcrypt");
> return -1;
> --
> 2.43.0
>
With 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:[~2024-01-22 14:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-19 20:39 [PATCH] crypto/gcrypt: prefer kernel as direct source of entropy Cristian Rodríguez
2024-01-22 14:48 ` Daniel P. Berrangé [this message]
2024-01-22 20:08 ` Cristian Rodríguez
2024-01-22 20:19 ` Daniel P. Berrangé
2024-01-22 20:21 ` Cristian Rodríguez
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=Za6ALDkMyW9Pdspd@redhat.com \
--to=berrange@redhat.com \
--cc=cristian@rodriguez.im \
--cc=qemu-devel@nongnu.org \
/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).