Re: [PATCH net-next 0/4] psp: make tx key ops optional for drivers

[Jakub Kicinski <kuba@kernel.org>]

On Tue, 08 Sep 2026 10:09:56 -0400 Daniel Zahka wrote:
> On Mon Sep 7, 2026 at 8:00 PM EDT, patchwork-bot+netdevbpf wrote:
> > On Thu, 03 Sep 2026 18:33:58 -0700 you wrote:  
> >> This is the first of two series which together implement rekeying PSP
> >> protected tcp connections. Here are both series together on github:
> >> https://github.com/danieldzahka/linux/commits/psp-rekey-split/
> >> 
> >> This first series is mostly non-functional changes, except for the minor
> >> difference that netdevsim driver implements tx key ops. Its tx key ops
> >> were basically NOPs, and in the future PSP core can subsume the assoc
> >> counting that it was doing.
>
> Thanks. I think applying was the right move, but I would like to
> highlight something that sashiko flagged on patch 4, as I think it will
> need to be addressed with its own series. The hazard is preexisting and
> much broader than the way sashiko talks about it. 

Ugh, yes, the complaint was sort of besides the point so Clashiko
has dropped it. But the problem behind it is real.

> The high level idea is that netdev core should probably take extra care
> to make sure users of sk_validate_xmit_skb (psp and ktls) cannot clobber
> what each other has set for that callback. In the case of psp vs. ktls,
> there are probably fundamental reasons why these should be kept mutually
> exclusive and their uapis should reject attempts to transition between
> them.
> 
> More generally however, any offloads wishing to claim
> sk_validate_xmit_skb should be considered mutually exclusive, and netdev
> core may benefit from a generic system to enforce ownership. That would
> help in case another user of sk_validate_xmit_skb comes along later.

There could also be confusion about the meaning of the decrypted bit in
the skb. Off the top of my head Rx TLS is shared between offload and
non-offload so SW TLS Rx ingesting a PSP packet may think that it was
TLS decrypted today. We should reject any TLS+PSP, not just
validate_xmit.

Both setup paths are under socket lock so it's a relatively
straightforward fix?