Re: [PATCH net-next v2 0/6] Deliver TLS control records to kernel read_sock consumers

On 7/20/26 4:27 PM, Chuck Lever wrote:
> When kTLS is active, kernel consumers of the read_sock API cannot
> see TLS control records: tls_sw_read_sock() rejects Alerts and
> Handshake records with -EINVAL. A consumer that needs those records
> falls back to sock_recvmsg() with ancillary buffers, which is why
> NFSD's svcsock runs a MSG_CTRUNC recovery dance on every receive.
> 
> This series adds a read_sock_rectype proto_ops method that delivers
> non-data records through a separate callback, then converts its first
> consumer, NFSD's svcsock, to use it. NFS client (xprtsock), NVMe
> target, and NVMe host are meant to move onto the same mechanism in
> later series. The existing read_sock data path is unchanged.
> 
> The improvement is more than cosmetic. All of these consumers need
> to handle TLS Alert messages efficiently and securely (in particular,
> for KeyUpdate). A few design points worth mentioning:
> 
> - The new sk_read_rectype_actor_t callback does not share the data
>    actor's byte-counting contract. It returns 0 to consume a record or
>    a negative value to requeue it and stop delivery. The return is
>    never a byte count. svc_tcp_rectype_actor() relies on this,
>    returning 0 to consume every non-data record while stopping the
>    read loop through desc->count on a fatal alert.
> 
> - The no-data cap (patch 1) is a prerequisite, not a stand-alone fix.
>    Once control records reach read_sock, a record carrying no payload
>    stops advancing the caller's read descriptor, so a peer streaming
>    such records would pin the socket lock and the kernel receive
>    context for as long as the flood lasts. Bounding consecutive
>    no-data records supplies the return boundary a system call would
>    otherwise provide. The cap is scoped to tls_sw_read_sock() alone:
>    splice and recvmsg run in the caller's own context, reschedule, and
>    drop the lock on return, so they need nothing.
> 
> - The svcsock conversion is split so the new path can be reviewed
>    against the old. The old path is then removed by the last patch
>    in the series.
> 
> - read_sock_rectype has no direct userspace entry point, so its
>    selftest coverage (patch 4) drives the shared decryption and
>    rx_list delivery pipeline through the recvmsg and splice paths
>    instead.
> 
> ---
> Changes in v2:
> - Renamed the read_sock_cmsg proto_ops method to read_sock_rectype.
> - Non-data records now use a record-type actor, not RFC cmsg-style.
> - Bound no-data records so they can't pin the socket lock (new patch 1).
> - Added selftests for data/control record interleaving (new patch 4).
> - Link to v1: https://lore.kernel.org/r/[email protected]
> 
> ---
> Chuck Lever (6):
>        net/tls: Bound consecutive no-data records in tls_sw_read_sock()
>        net: Introduce read_sock_rectype proto_ops for control record delivery
>        tls: Implement read_sock_rectype for kTLS software path
>        selftests/tls: Add tests for data/control record interleaving
>        SUNRPC: Use read_sock_rectype for svcsock TCP receives
>        SUNRPC: Remove sock_recvmsg path from svcsock TCP receives
> 
>   include/linux/net.h               |  28 +++
>   net/sunrpc/svcsock.c              | 381 +++++++++++++++++---------------------
>   net/tls/tls.h                     |   3 +
>   net/tls/tls_main.c                |   5 +
>   net/tls/tls_sw.c                  |  54 +++++-
>   tools/testing/selftests/net/tls.c | 298 ++++++++++++++++++++++++++++-
>   6 files changed, 556 insertions(+), 213 deletions(-)
> ---
> base-commit: 298bb2b8903323f6ef2eab4819a2e477765f0ff1
> change-id: 20260327-tcp-read-sock-778a49660ff7
> 
> Best regards,
> --
> Chuck Lever <[email protected]>
> 
> 

Good stuff. I was tempted to say 'We need it', but meanwhile we found
during spec review that the REPLACETLSPSK mechanism as defined in the
spec is at odds with the TLS KeyUpdate.
So while we (from the NVMe side) might be wanting to use it eventually,
we first have to figure out how to interact sanely between the NVMe
and TLS layer.

And I don't feel qualified to judge on NFS/SunRPC details, so didn't
dare to do a review here.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
[email protected]                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich