On Thu Sep 10, 2026 at 7:46 PM EDT, Daniel Zahka wrote:
> PSP conflicts with TLS ULP in its usage of both skb->decrypted and
> sk->sk_validate_xmit_skb(). Offloaded TLS conflicts on both sides in
> both Tx and Rx. SW TLS could mistake skb->decrypted in the Rx path set
> by a PSP device as being a decrypted TLS record.
>
> Prevent PSP from being used with other socket features that use
> skb->decrypted or sk->sk_validate_xmit_skb().
>
> For now, we include all TCP ULPs in the sk_has_decrypt_user() check,
> even though TLS is the only one that conflicts with PSP via the
> decrypted bit. This is intentional because PSP was not designed to be
> used with ULPs. It is best to close off surface area that may make bugs
> reachable, until someone wishes to design and test an actual user of PSP
> with ULPs.
>
> Fixes: 6b46ca260e22 ("net: psp: add socket security association code")
> Signed-off-by: Daniel Zahka <[email protected]>
> ---sashiko and clashiko both point out that sk_clone() is still broken if the listener socket has psp assoc tx state. In this case, the sk->sk_validate_xmit_skb function is not cleared out in the cloned socket. In sashiko's eyes, this patch constitutes a regression, because before the stale validate callback would mostly just be a waste of instructions on the child socket, whereas after this commit the child, without psp assoc state, would be ineligible for rx assoc. I think we should remove the ability to attach psp assoc state to listener sockets. I don't see a simple path towards making that a useful feature given the current model we have for psp that is very much geared towards upgrading from established state. As a reference, Google's psp repo [1] demonstrates listening sockets accepting a psp encrypted TCP SYN, and replying with an encrypted SYN ACK. To make that work requires exchanging keys beforehand, and pre installing the psp state per connection on the listening socket. That is a completely different connection model. [1]: https://github.com/google/psp/tree/linux-v5.15-psp-v1.0
