mirrors/linux
2
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git synced 2026-07-22 02:17:36 -04:00
Code Issues Packages Projects Releases Wiki Activity

docs: net: tls-offload: document tls_dev_del, tls_dev_resync, and rekey

Browse Source 
Fill in some gaps in the TLS offload doc:

- describe the tls_dev_del and tls_dev_resync callbacks
- add a mention of rekeying being out of scope for now

Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
Link: https://patch.msgid.link/20260613165846.2913092-2-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This commit is contained in:
Jakub Kicinski
2026-06-13 09:58:44 -07:00
parent a61bb36996
commit c8ee634048
1 changed files with 38 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

45
Documentation/networking/tls-offload.rst
View File

@@ -99,6 +99,29 @@ at the end of kernel structures (see :c:member:`driver_state` members
in ``include/net/tls.h``) to avoid additional allocations and pointer
dereferences.
When the offloaded connection is destroyed the core calls
the :c:member:`tls_dev_del` callback so the driver can release per-direction
state:
.. code-block:: c
void (*tls_dev_del)(struct net_device *netdev,
struct tls_context *ctx,
enum tls_offload_ctx_dir direction);
``tls_dev_del`` is mandatory whenever ``tls_dev_add`` is provided.
The third TLS device callback is :c:member:`tls_dev_resync`, called by the core
to synchronize the TCP stream with the record boundaries:
.. code-block:: c
int (*tls_dev_resync)(struct net_device *netdev,
struct sock *sk, u32 seq, u8 *rcd_sn,
enum tls_offload_ctx_dir direction);
See the `Resync handling`_ section for details.
TX
--
@@ -250,9 +273,9 @@ Following helper should be used to test if resync is complete:
bool tls_offload_tx_resync_pending(struct sock *sk)
Next time ``ktls`` pushes a record it will first send its TCP sequence number
and TLS record number to the driver. Stack will also make sure that
the new record will start on a segment boundary (like it does when
the connection is initially added).
and TLS record number to the driver via the ``tls_dev_resync`` callback.
The stack will also make sure that the new record will start on a segment
boundary (like it does when the connection is initially added).
RX
--
@@ -344,9 +367,10 @@ all TLS record headers that have been logged since the resync request
started.
The kernel confirms the guessed location was correct and tells the device
the record sequence number. Meanwhile, the device had been parsing
and counting all records since the just-confirmed one, it adds the number
of records it had seen to the record number provided by the kernel.
the record sequence number via the ``tls_dev_resync`` callback. Meanwhile,
the device had been parsing and counting all records since the just-confirmed
one, it adds the number of records it had seen to the record number provided
by the kernel.
At this point the device is in sync and can resume decryption at next
segment boundary.
@@ -370,12 +394,19 @@ schedules resynchronization after it has received two completely encrypted
records.
The stack waits for the socket to drain and informs the device about
the next expected record number and its TCP sequence number. If the
the next expected record number and its TCP sequence number via the
``tls_dev_resync`` callback. If the
records continue to be received fully encrypted stack retries the
synchronization with an exponential back off (first after 2 encrypted
records, then after 4 records, after 8, after 16... up until every
128 records).
Rekey
=====
Offload does not currently support TLS 1.3, therefore key rotation
is not a concern for offloaded connections at this point.
Error handling
==============