From: Paolo Abeni <pabeni@redhat.com>
To: Rishikesh Jethwani <rjethwani@purestorage.com>, netdev@vger.kernel.org
Cc: saeedm@nvidia.com, tariqt@nvidia.com, mbloch@nvidia.com,
borisp@nvidia.com, john.fastabend@gmail.com, kuba@kernel.org,
sd@queasysnail.net, davem@davemloft.net, edumazet@google.com,
leon@kernel.org
Subject: Re: [PATCH v13 5/6] tls: add hardware offload key update support
Date: Tue, 5 May 2026 10:40:41 +0200 [thread overview]
Message-ID: <64d71f18-f86b-4fd7-a6bd-02243eed0492@redhat.com> (raw)
In-Reply-To: <20260429181016.3164935-6-rjethwani@purestorage.com>
On 4/29/26 8:10 PM, Rishikesh Jethwani wrote:
> On TX, the NIC key cannot be replaced while HW-offloaded records
> are still unacked. tls_dev_start_rekey() installs a temporary SW
> context with the new key and redirects sendmsg through
> tls_sw_sendmsg_locked. If no records are pending,
> tls_dev_complete_rekey() runs inline during setsockopt; otherwise
> clean_acked sets REKEY_READY once all old-key records are ACKed
> and the next sendmsg completes the rekey, flushing SW records and
> reinstalling HW offload at the current write_seq. A KeyUpdate
> arriving while one is pending re-keys the SW AEAD in place; if the
> HW reinstall fails the socket stays in SW mode (REKEY_FAILED).
>
> On RX, the NIC may have already decrypted in-flight records with
> the old key before the peer's KeyUpdate is parsed, so the old
> AEAD, IV and rec_seq are retained on tls_offload_context_rx.
> tls_check_pending_rekey() invokes tls_device_rx_del_key() to drop
> the NIC key; otherwise post-KeyUpdate records (carrying new-key
> wire encryption) would be XOR'd with the retired key.
> tls_device_decrypted() classifies records by old_nic_boundary:
>
> - after the boundary: new-key record; drop the old key.
> - before, fully encrypted: advance old_rec_seq, let SW AEAD decrypt.
> - before, (partially) decrypted: reencrypt with the old key so SW
> AEAD can decrypt with the new key.
>
> For mixed records skb->decrypted flags can be wrong (NIC clears
> them on auth failure); on -EBADMSG, tls_rx_rekey_retry() toggles
> those flags, decrements old_rec_seq to reuse the nonce, and
> retries once (gated by old_key_reencrypted).
>
> The new key's tls_dev_add is deferred until the old key is fully
> consumed: tls_set_device_offload_rx() sets dev_add_pending while
> old_aead_recv is retained, and tls_device_deferred_dev_add()
> installs the new key once copied_seq crosses old_nic_boundary.
>
> Tested on Mellanox ConnectX-6 Dx (Crypto Enabled) with multiple
> TLS 1.3 TX and RX KeyUpdate cycles.
>
> Signed-off-by: Rishikesh Jethwani <rjethwani@purestorage.com>
> ---
> include/net/tls.h | 84 +++-
> include/uapi/linux/snmp.h | 2 +
> net/tls/tls.h | 29 +-
> net/tls/tls_device.c | 753 +++++++++++++++++++++++++++++++---
> net/tls/tls_device_fallback.c | 24 ++
> net/tls/tls_main.c | 92 +++--
> net/tls/tls_proc.c | 2 +
> net/tls/tls_sw.c | 76 +++-
> net/tls/trace.h | 79 ++++
This patch is really big and complex and you should break it to help
reviewers.
At very least you can split out the tracing bits and the trivial
refactor moving around declaration and definitions to separate patches.
/P
next prev parent reply other threads:[~2026-05-05 8:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-29 18:10 [PATCH net-next v13 0/6] tls: Add TLS 1.3 hardware offload support Rishikesh Jethwani
2026-04-29 18:10 ` [PATCH v13 1/6] net: tls: reject TLS 1.3 offload in chcr_ktls and nfp drivers Rishikesh Jethwani
2026-04-29 18:10 ` [PATCH v13 2/6] net/mlx5e: add TLS 1.3 hardware offload support Rishikesh Jethwani
2026-04-29 18:10 ` [PATCH v13 3/6] tls: " Rishikesh Jethwani
2026-04-29 18:10 ` [PATCH v13 4/6] tls: split tls_set_sw_offload into init and finalize stages Rishikesh Jethwani
2026-04-29 18:10 ` [PATCH v13 5/6] tls: add hardware offload key update support Rishikesh Jethwani
2026-05-05 8:40 ` Paolo Abeni [this message]
2026-05-05 8:41 ` Paolo Abeni
2026-04-29 18:10 ` [PATCH v13 6/6] selftests: net: add TLS hardware offload test Rishikesh Jethwani
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=64d71f18-f86b-4fd7-a6bd-02243eed0492@redhat.com \
--to=pabeni@redhat.com \
--cc=borisp@nvidia.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=mbloch@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=rjethwani@purestorage.com \
--cc=saeedm@nvidia.com \
--cc=sd@queasysnail.net \
--cc=tariqt@nvidia.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