Re: [PATCH v3 1/2] tls: TLS 1.3 hardware offload support
From: Rishikesh Jethwani <hidden>
Date: 2026-01-21 22:18:01
in
I don't see you handling re-keying, which is supported in SW.
Added hardware offload key update support in v4
quoted
The upstream Broadcom bnxt_en driver does not yet support kTLS offload. Testing was performed using the out-of-tree driver version bnxt_en-1.10.3-235.1.154.0, which works without modifications.It's a bit odd to mention that you tested some out of tree code. Glad it works, but I don't see the relevance upstream. Please drop the mentions of Broadcom until the driver has TLS offload support added.
Removed Broadcom bnxt_en out-of-tree driver mention in v4
quoted
--- a/net/tls/tls_device.c +++ b/net/tls/tls_device.c@@ -319,6 +319,36 @@ static void tls_device_record_close(struct sock *sk, struct tls_prot_info *prot = &ctx->prot_info; struct page_frag dummy_tag_frag; + /* TLS 1.3: append content type byte before tag. + * Record structure: [Header (5)] + [Ciphertext + ContentType (1)] + [Tag (16)] + * The content type is encrypted with the ciphertext for authentication. + */ + if (prot->version == TLS_1_3_VERSION) { + struct page_frag dummy_content_type_frag; + struct page_frag *content_type_pfrag = pfrag; + + /* Validate record type range */ + if (unlikely(record_type < TLS_RECORD_TYPE_CHANGE_CIPHER_SPEC || + record_type > TLS_RECORD_TYPE_ACK)) { + pr_err_once("tls_device: invalid record type %u\n", + record_type); + return;This check is really odd. Why is it relevant, and yet not relevant enough to handle cleanly? On a quick look it appears that the user can set whatever content type they want.
Removed record_type check from tls_device_record_close() in v4
quoted
+ + if (unlikely(pfrag->size - pfrag->offset < prot->tail_size) && + !skb_page_frag_refill(prot->tail_size, pfrag, sk->sk_allocation)) { + /* Out of memory: use pre-populated dummy_page */ + dummy_content_type_frag.page = dummy_page; + dummy_content_type_frag.offset = record_type; + content_type_pfrag = &dummy_content_type_frag; + } else { + /* Current pfrag has space or allocation succeeded - write content type */ + *(unsigned char *)(page_address(pfrag->page) + pfrag->offset) = + record_type;wrap at 80chars and please refactor this long line into something more readable.
Refactored in v4
quoted
+ } + tls_append_frag(record, content_type_pfrag, prot->tail_size); + } + /* append tag * device will fill in the tag, we just need to append a placeholder * use socket memory to improve coalescing (re-using a single buffer@@ -335,7 +365,7 @@ static void tls_device_record_close(struct sock *sk, /* fill prepend */ tls_fill_prepend(ctx, skb_frag_address(&record->frags[0]), - record->len - prot->overhead_size, + (record->len - prot->overhead_size) + prot->tail_size, record_type); }@@ -1089,7 +1119,8 @@ int tls_set_device_offload(struct sock *sk) } crypto_info = &ctx->crypto_send.info; - if (crypto_info->version != TLS_1_2_VERSION) { + if (crypto_info->version != TLS_1_2_VERSION && + crypto_info->version != TLS_1_3_VERSION) { rc = -EOPNOTSUPP; goto release_netdev; }Are all existing drivers rejecting TLS 1.3 sessions? These days we prefer for drivers to explicitly opt into new features to avoid surprises.
Yes, currently the following 3 drivers support tls offload and all of them reject TLS 1.3 sessions. - drivers/net/ethernet/chelsio/inline_crypto/chtls - drivers/net/ethernet/fungible/funeth/ - drivers/net/ethernet/mellanox/mlx5/core/en_accel/