Linux TLS stack gains TLS 1.3 hardware offload and rekey

The Linux kernel TLS hardware offload path is set to support TLS 1.3, including in-connection KeyUpdate, under a 15-part series Rishikesh Jethwani posted to the netdev list for net-next.

Kernel TLS has long been able to hand AES-GCM crypto to capable NICs for TLS 1.2. TLS 1.3 uses a different record layout and IV model, and its mandatory rekey (KeyUpdate) means the offload state of a live socket can change mid-flow. Until now the device path rejected 1.3 and had no safe way to swap keys without falling back to software or risking cleartext on the wire.

The series opens 1.3 TX and RX offload in the core TLS device code and in the mlx5 driver for ConnectX-6 Dx and newer crypto-enabled adapters, covering AES-GCM-128 and AES-GCM-256. Chelsio and Netronome kTLS drivers, which only implement 1.2, explicitly refuse 1.3 so unsupported hardware is not engaged.

KeyUpdate is the harder piece. On TX, a temporary software context carries traffic under the new key until old-key records are acknowledged, then hardware is reinstalled. On RX, the stack keeps the retired AEAD long enough to finish records the NIC still decrypted with the old key, classifies packets against a sequence boundary, and re-encrypts mixed or failed records so software can authenticate them. qdisc requeue now re-validates decrypted skbs after offload state changes, and a TCP collapse fence is extended so post-key data cannot merge into a pre-key skb and leave the NIC in cleartext. That fence fix also matters for PSP, which uses the same decrypted marking.

Selftests and documentation for the rekey path ship with the series. Jethwani reports testing on ConnectX-6 Dx; Tariq Toukan of NVIDIA reviewed and tested the mlx5 portions.