Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider:
Critical: 0 · High: 0 · Medium: 0 · Low: 1
- [Low] The patch adds a new, user-visible restriction to two already-
shipped interfaces without updating Documentation/networking/psp.rst:…
--
net: psp: avoid conflicts with skb->decrypted and sk_validate_xmit_skb()
This makes PSP and TCP ULPs mutually exclusive, since PSP and TLS both use
skb->decrypted and sk->sk_validate_xmit_skb(). A new helper
sk_has_decrypt_user() is added and checked from both __tcp_set_ulp() and
psp_sock_assoc_set_rx().
> diff --git a/net/core/sock.c b/net/core/sock.c
> index fa60b7494c586..9489d9c479493 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
[ ... ]
> @@ -2670,6 +2671,12 @@ void sk_setup_caps(struct sock *sk, struct dst_entry
> *dst)
> }
> EXPORT_SYMBOL_GPL(sk_setup_caps);
>
> +bool sk_has_decrypt_user(const struct sock *sk)
> +{
> + return psp_sk_assoc(sk) ||
> + (sk_is_inet(sk) && inet_csk_has_ulp(sk)); /* for tls */
> +}
> +
> /*
> * Simple resource managers for sockets.
> */
> diff --git a/net/ipv4/tcp_ulp.c b/net/ipv4/tcp_ulp.c
> index 2aa442128630e..b58045df101e5 100644
> --- a/net/ipv4/tcp_ulp.c
> +++ b/net/ipv4/tcp_ulp.c
> @@ -136,6 +136,10 @@ static int __tcp_set_ulp(struct sock *sk, const struct
> tcp_ulp_ops *ulp_ops)
> if (icsk->icsk_ulp_ops)
> goto out_err;
>
> + err = -EINVAL;
> + if (sk_has_decrypt_user(sk))
> + goto out_err;
> +
> if (sk->sk_socket)
> clear_bit(SOCK_SUPPORT_ZC, &sk->sk_socket->flags);
>
> diff --git a/net/psp/psp_sock.c b/net/psp/psp_sock.c
> index 1a2a6b7516b0f..e9b53eedf8dba 100644
> --- a/net/psp/psp_sock.c
> +++ b/net/psp/psp_sock.c
> @@ -143,6 +143,10 @@ int psp_sock_assoc_set_rx(struct sock *sk, struct
> psp_assoc *pas,
> NL_SET_ERR_MSG(extack, "Socket already has PSP state");
> err = -EBUSY;
> goto exit_unlock;
> + } else if (sk_has_decrypt_user(sk)) {
> + NL_SET_ERR_MSG(extack, "Socket has incompatible state");
> + err = -EINVAL;
> + goto exit_unlock;
> }
[Severity: Low]
Should Documentation/networking/psp.rst be updated along with this?
Two already-shipped interfaces grow a new failure mode here:
psp_sock_assoc_set_rx() now returns -EINVAL for the rx-assoc netlink
command, and __tcp_set_ulp() now returns -EINVAL for
setsockopt(TCP_ULP).
The "Securing a connection" section enumerates the restrictions of the
rx-assoc/tx-assoc sequence:
PSP encryption is currently only supported for TCP connections.
Rx and Tx keys are allocated separately. First the ``rx-assoc``
Netlink command needs to be issued, specifying a target TCP socket.
but does not mention that a socket with a ULP attached is now rejected.
The "User facing API" section also suggests a TLS-then-PSP bootstrap:
The expectation is that higher layer protocols will take care of
protocol and key negotiation. For example one may use TLS key exchange,
announce the PSP capability, and switch to PSP if both endpoints
are PSP-capable.
and "Kernel implementation notes" says PSP "follows the TLS offload more
closely ... and the use of skb->decrypted", with nothing stating that kTLS
and PSP can no longer share a socket.
One more thing worth spelling out in the docs: the check is not restricted
to TLS. inet_csk_has_ulp() only tests icsk_ulp_ops, so any registered TCP
ULP blocks rx-assoc, which is broader than the subject line suggests. The
commit message explains this is intentional, but nothing in-tree tells
userspace about it.
The follow-up patch in the series ("selftests: drv-net: psp: test PSP and
TCP ULP mutual exclusion") adds tests for both directions but does not
touch Documentation/, so the gap remains at the end of the series.
--
Sashiko AI review ·
https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260915-psp-ktls-fix-v2-0-0eedc3b148ec%40gmail.com
