From: Fabiano Rosas <farosas@suse.de>
To: "Daniel P. Berrangé" <berrange@redhat.com>, qemu-devel@nongnu.org
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Peter Xu" <peterx@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>
Subject: Re: [PATCH 1/4] crypto: implement workaround for GNUTLS thread safety problems
Date: Mon, 21 Jul 2025 16:19:46 -0300 [thread overview]
Message-ID: <87wm81xsfh.fsf@suse.de> (raw)
In-Reply-To: <20250718150514.2635338-2-berrange@redhat.com>
Daniel P. Berrangé <berrange@redhat.com> writes:
> When TLS 1.3 is negotiated on a TLS session, GNUTLS will perform
> automatic rekeying of the session after 16 million records. This
> is done for all algorithms except CHACHA20_POLY1305 which does
> not require rekeying.
>
> Unfortunately the rekeying breaks GNUTLS' promise that it is safe
> to use a gnutls_session_t object concurrently from multiple threads
> if they are exclusively calling gnutls_record_send/recv.
>
> This patch implements a workaround for QEMU that adds a mutex lock
> around any gnutls_record_send/recv call to serialize execution
> within GNUTLS code. When GNUTLS calls into the push/pull functions
> we can release the lock so the OS level I/O calls can at least
> have some parallelism.
>
> The big downside of this is that the actual encryption/decryption
> code is fully serialized, which will halve performance of that
> cipher operations if two threads are contending.
>
> The workaround is not enabled by default, since most use of GNUTLS
> in QEMU does not tickle the problem, only non-multifd migration
> with a return path open is affected. Fortunately the migration
> code also won't trigger the halving of performance, since only
> the outbound channel diretion needs to sustain high data rates,
> the inbound direction is low volume.
>
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Hi, the CI caught a couple of issues. I'll fixup on the branch, no need
to resend.
...
> +void qcrypto_tls_session_require_thread_safety(QCryptoTLSSession *sess)
> +{
> + sess->requireThreadSafety = true;
> +}
Needs a stub.
...
> @@ -545,8 +600,29 @@ int
> qcrypto_tls_session_handshake(QCryptoTLSSession *session,
> Error **errp)
> {
> - int ret = gnutls_handshake(session->handle);
> + int ret;
> + ret = gnutls_handshake(session->handle);
> +
> if (!ret) {
> + gnutls_cipher_algorithm_t cipher =
> + gnutls_cipher_get(session->handle);
> +
Unused var when the config is not enabled.
> +#ifdef CONFIG_GNUTLS_BUG1717_WORKAROUND
> + /*
> + * Any use of rekeying in TLS 1.3 is unsafe for
> + * a gnutls with bug 1717, however, we know that
> + * QEMU won't initiate manual rekeying. Thus we
> + * only have to protect against automatic rekeying
> + * which doesn't trigger with CHACHA20
> + */
> + if (session->requireThreadSafety &&
> + gnutls_protocol_get_version(session->handle) ==
> + GNUTLS_TLS1_3 &&
> + cipher != GNUTLS_CIPHER_CHACHA20_POLY1305) {
> + session->lockEnabled = true;
> + }
> +#endif
> +
> session->handshakeComplete = true;
> return QCRYPTO_TLS_HANDSHAKE_COMPLETE;
> }
next prev parent reply other threads:[~2025-07-21 19:25 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-18 15:05 [PATCH 0/4] migration: workaround GNUTLS live migration crashes Daniel P. Berrangé
2025-07-18 15:05 ` [PATCH 1/4] crypto: implement workaround for GNUTLS thread safety problems Daniel P. Berrangé
2025-07-21 14:52 ` Fabiano Rosas
2025-07-21 19:19 ` Fabiano Rosas [this message]
2025-07-18 15:05 ` [PATCH 2/4] io: add support for activating TLS thread safety workaround Daniel P. Berrangé
2025-07-21 14:52 ` Fabiano Rosas
2025-07-18 15:05 ` [PATCH 3/4] migration: activate " Daniel P. Berrangé
2025-07-21 14:52 ` Fabiano Rosas
2025-07-18 15:05 ` [PATCH 4/4] crypto: add tracing & warning about GNUTLS countermeasures Daniel P. Berrangé
2025-07-21 14:52 ` Fabiano Rosas
2025-07-21 19:32 ` Fabiano Rosas
2025-07-21 14:56 ` [PATCH 0/4] migration: workaround GNUTLS live migration crashes Fabiano Rosas
2025-07-21 15:03 ` Daniel P. Berrangé
2025-07-21 15:14 ` Fabiano Rosas
2025-07-21 15:28 ` Daniel P. Berrangé
2025-07-26 6:24 ` Michael Tokarev
2025-07-28 9:04 ` 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=87wm81xsfh.fsf@suse.de \
--to=farosas@suse.de \
--cc=berrange@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--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).