Linux kTLS adds TLS 1.3 hardware offload and KeyUpdate

Kernel TLS can now hardware-offload TLS 1.3 connections, including KeyUpdate rekeying, on NICs that implement the feature. The change closes a long-standing gap: production stacks have moved to TLS 1.3, but kTLS device offload was effectively stuck on TLS 1.2, so encrypted bulk traffic still burned host CPU on modern cipher suites.

Rishikesh Jethwani of Pure Storage posted the work to the netdev list. It extends the generic kTLS device path for the TLS 1.3 record layout (content type carried with the tag, different IV construction) and teaches the mlx5 driver to offload TLS 1.3 AES-GCM on ConnectX-6 Dx and newer crypto-enabled adapters. Drivers that only ever supported TLS 1.2, including Chelsio chcr_ktls and Netronome nfp, now reject 1.3 offload requests cleanly instead of attempting an unsupported setup.

KeyUpdate is the harder part. On transmit, the NIC cannot swap keys while old-key records are still unacknowledged, so the stack briefly redirects sends through a software context with the new key, then reinstalls hardware offload once those records are ACKed. On receive, in-flight records may already have been decrypted under the old key; the code tracks a boundary, re-encrypts mixed records when needed, and defers installing the new NIC key until the old one is fully consumed. If hardware reinstall fails, the socket stays in software mode rather than tearing down the connection.

NVIDIA's Tariq Toukan reviewed and tested the mlx5 pieces. A new selftest drives client/server offload across TLS 1.2 and 1.3, AES-GCM-128/256, and bursty rekey patterns, checking the related SNMP counters. The series targets net-next as v16 after earlier review.