netdev - Re: [RFC 1/4] net/handshake: get negotiated tls record size limit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2a9c71e0-f29d-46b6-823d-a957b10b4858@suse.de>
Date: Tue, 29 Jul 2025 10:12:49 +0200
From: Hannes Reinecke <hare@...e.de>
To: Wilfred Mallawa <wilfred.opensource@...il.com>, alistair.francis@....com,
 dlemoal@...nel.org, chuck.lever@...cle.com, davem@...emloft.net,
 edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, horms@...nel.org,
 donald.hunter@...il.com, corbet@....net, kbusch@...nel.org, axboe@...nel.dk,
 hch@....de, sagi@...mberg.me, kch@...dia.com, borisp@...dia.com,
 john.fastabend@...il.com, jlayton@...nel.org, neil@...wn.name,
 okorniev@...hat.com, Dai.Ngo@...cle.com, tom@...pey.com, trondmy@...nel.org,
 anna@...nel.org, kernel-tls-handshake@...ts.linux.dev, netdev@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
 linux-nvme@...ts.infradead.org, linux-nfs@...r.kernel.org,
 Wilfred Mallawa <wilfred.mallawa@....com>
Subject: Re: [RFC 1/4] net/handshake: get negotiated tls record size limit

On 7/29/25 04:41, Wilfred Mallawa wrote:
> From: Wilfred Mallawa <wilfred.mallawa@....com>
> 
> During a handshake, an endpoint may specify a maximum record size limit.
> Currently, this limit is not visble to the kernel particularly in the case
> where userspace handles the handshake (tlshd/gnutls). This patch adds
> support for retrieving the record size limit.
> 
> This is the first step in ensuring that the kernel can respect the record
> size limit imposed by the endpoint.
> 
> Signed-off-by: Wilfred Mallawa <wilfred.mallawa@....com>
> ---
>   Documentation/netlink/specs/handshake.yaml |  3 +++
>   Documentation/networking/tls-handshake.rst |  8 +++++++-
>   drivers/nvme/host/tcp.c                    |  3 ++-
>   drivers/nvme/target/tcp.c                  |  3 ++-
>   include/net/handshake.h                    |  4 +++-
>   include/uapi/linux/handshake.h             |  1 +
>   net/handshake/genl.c                       |  5 +++--
>   net/handshake/tlshd.c                      | 15 +++++++++++++--
>   net/sunrpc/svcsock.c                       |  4 +++-
>   net/sunrpc/xprtsock.c                      |  4 +++-
>   10 files changed, 40 insertions(+), 10 deletions(-)
> 
> diff --git a/Documentation/netlink/specs/handshake.yaml b/Documentation/netlink/specs/handshake.yaml
> index b934cc513e3d..35d5eb91a3f9 100644
> --- a/Documentation/netlink/specs/handshake.yaml
> +++ b/Documentation/netlink/specs/handshake.yaml
> @@ -84,6 +84,9 @@ attribute-sets:
>           name: remote-auth
>           type: u32
>           multi-attr: true
> +      -
> +        name: record-size-limit
> +        type: u32
>   
>   operations:
>     list:
> diff --git a/Documentation/networking/tls-handshake.rst b/Documentation/networking/tls-handshake.rst
> index 6f5ea1646a47..cd984a137779 100644
> --- a/Documentation/networking/tls-handshake.rst
> +++ b/Documentation/networking/tls-handshake.rst
> @@ -169,7 +169,8 @@ The synopsis of this function is:
>   .. code-block:: c
>   
>     typedef void	(*tls_done_func_t)(void *data, int status,
> -                                   key_serial_t peerid);
> +                                   key_serial_t peerid,
> +                                   size_t tls_record_size_limit);
>   
>   The consumer provides a cookie in the @ta_data field of the
>   tls_handshake_args structure that is returned in the @data parameter of

Why is this exposed to the TLS handshake consumer?
The TLS record size is surely required for handling and processing TLS
streams in net/tls, but the consumer of that (eg NVMe-TCP, NFS)
are blissfully unaware that there _are_ such things like TLS records.
And they really should keep it that way.

So I'd really _not_ expose that to any ULP and keep it internal to
the TLS layer.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@...e.de                                +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