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

["Daniel Zahka" <daniel.zahka@gmail.com>]

On Tue Sep 8, 2026 at 1:33 PM EDT, Jakub Kicinski wrote:
> 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? 

Yes. I'll put a fix together.