Re: [PATCH v13 5/6] tls: add hardware offload key update support

[Sabrina Dubroca <sd@queasysnail.net>]

2026-05-12, 10:55:35 -0700, Rishikesh Jethwani wrote:
> > Not blaming you for NIC behavior, but... the NIC passes up as
> > "decrypted" records that have failed decryption (because it was using
> > the wrong (old) key), or passes as "encrypted" the incorrectly
> > decrypted data (that it has "decrypted" with the old key)?
> >
> > Or this is only the first record(s) after the KeyUpdate message, if
> > they fall within the same packet, the whole packet was "decrypted"
> > with the old key but only the KeyUpdate itself (and maybe some more
> > records before it) decrypted correctly ; but subsequent packets get
> > passed as !decrypted and don't need this reencrypt dance?
> >
> > (this is maybe more of a question for Tariq or the other @nvidia
> > folks)
> >
> >
> > I haven't reviewed the whole patch at this point, because of Paolo's
> > suggestion and this confusion with the RX rekey.
> >
> > The traces show how both NICs behave during the key transition:
> 
>   Broadcom (NIC preserves decrypted flags):
>   - decrypted=1: NIC fully decrypted these with the old key; one reencrypt
> pass (retry=0) re-encrypts those frags back to ciphertext, then SW decrypts
> with the new key.
>   - encrypted=0, decrypted=0: boundary-straddling record; same single
> reencrypt pass.
>   - encrypted=1: NIC never touched these; SW decrypts directly with the new
> key.
> 
>   Mellanox (NIC clears decrypted flags on auth failure):
>   - encrypted=0, decrypted=0: NIC partially processed the record but
> cleared all decrypted flags on auth failure. retry=0 reencrypts with the
> wrong frag interpretation and gets EBADMSG; retry=1 toggles the flags and
> succeeds.
>   - encrypted=1: NIC reported these as untouched; SW decrypts directly.
> 
>   The retry path exists specifically for the Mellanox case: cleared flags
> hide which frags the NIC actually touched, so the first pass may pick the
> wrong interpretation and need to flip it.

Thanks for describing this.

I don't think the core TLS implementation should implement workarounds
for HW/drivers doing strange things. IMO this should instead be
stuffed into a driver CB, which would implement the necessary steps to
perform during a rekey.

The core can provide a helper, but I would move the whole
"reencrypt+maybe retry" logic to a CB.

-- 
Sabrina