From: Damien Le Moal <dlemoal@kernel.org>
To: Wilfred Mallawa <wilfred.opensource@gmail.com>,
alistair.francis@wdc.com, chuck.lever@oracle.com,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, horms@kernel.org, donald.hunter@gmail.com,
corbet@lwn.net, kbusch@kernel.org, axboe@kernel.dk, hch@lst.de,
sagi@grimberg.me, kch@nvidia.com, borisp@nvidia.com,
john.fastabend@gmail.com, jlayton@kernel.org, neil@brown.name,
okorniev@redhat.com, Dai.Ngo@oracle.com, tom@talpey.com,
trondmy@kernel.org, anna@kernel.org,
kernel-tls-handshake@lists.linux.dev, netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-nvme@lists.infradead.org, linux-nfs@vger.kernel.org,
Wilfred Mallawa <wilfred.mallawa@wdc.com>
Subject: Re: [RFC 1/4] net/handshake: get negotiated tls record size limit
Date: Tue, 29 Jul 2025 17:07:54 +0900 [thread overview]
Message-ID: <624296dc-69d6-4bdd-bed1-ffcb747fb96d@kernel.org> (raw)
In-Reply-To: <20250729024150.222513-4-wilfred.opensource@gmail.com>
On 7/29/25 11:41, Wilfred Mallawa wrote:
> From: Wilfred Mallawa <wilfred.mallawa@wdc.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@wdc.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
> @@ -200,6 +201,11 @@ The @peerid parameter contains the serial number of a key containing the
> remote peer's identity or the value TLS_NO_PEERID if the session is not
> authenticated.
>
> +The @tls_record_size_limit parameter, if non-zero, exposes the tls max
> +record size advertised by the endpoint. Record size must not exceed this amount.
> +A negative value shall indicate that the endpoint did not advertise the
> +maximum record size limit.
size_t cannot be negative... Did you mean:
"A value of 0 (TLS_NO_RECORD_SIZE_LIMIT)..."
Also note that even if the endpoint does not advertize a record sie limit, we
still have one (16K was it ?). So I think that the name TLS_NO_RECORD_SIZE_LIMIT
is a little misleading.
> +
> A best practice is to close and destroy the socket immediately if the
> handshake failed.
[...]
> diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
> index e1c85123b445..2014d906ff06 100644
> --- a/net/sunrpc/svcsock.c
> +++ b/net/sunrpc/svcsock.c
> @@ -417,13 +417,15 @@ static void svc_tcp_kill_temp_xprt(struct svc_xprt *xprt)
> * @data: address of xprt to wake
> * @status: status of handshake
> * @peerid: serial number of key containing the remote peer's identity
> + * @tls_record_size_limit: Max tls_record_size_limit of the endpoint
Please make a proper sentence to describe tls_record_size_limit instead of
repeating that argument name.
> *
> * If a security policy is specified as an export option, we don't
> * have a specific export here to check. So we set a "TLS session
> * is present" flag on the xprt and let an upper layer enforce local
> * security policy.
> */
> -static void svc_tcp_handshake_done(void *data, int status, key_serial_t peerid)
> +static void svc_tcp_handshake_done(void *data, int status, key_serial_t peerid,
> + size_t tls_record_size_limit)
> {
> struct svc_xprt *xprt = data;
> struct svc_sock *svsk = container_of(xprt, struct svc_sock, sk_xprt);
> diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
> index 04ff66758fc3..509aa6269b0a 100644
> --- a/net/sunrpc/xprtsock.c
> +++ b/net/sunrpc/xprtsock.c
> @@ -2569,9 +2569,11 @@ static int xs_tcp_tls_finish_connecting(struct rpc_xprt *lower_xprt,
> * @data: address of xprt to wake
> * @status: status of handshake
> * @peerid: serial number of key containing the remote's identity
> + * @tls_record_size_limit: Max tls_record_size_limit of the endpoint
Same here.
> *
> */
> -static void xs_tls_handshake_done(void *data, int status, key_serial_t peerid)
> +static void xs_tls_handshake_done(void *data, int status, key_serial_t peerid,
> + size_t tls_record_size_limit)
> {
> struct rpc_xprt *lower_xprt = data;
> struct sock_xprt *lower_transport =
--
Damien Le Moal
Western Digital Research
next prev parent reply other threads:[~2025-07-29 8:07 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-29 2:41 [RFC 0/4] net/tls: add support for the record size limit extension Wilfred Mallawa
2025-07-29 2:41 ` [RFC 1/4] net/handshake: get negotiated tls record size limit Wilfred Mallawa
2025-07-29 8:07 ` Damien Le Moal [this message]
2025-07-29 8:12 ` Hannes Reinecke
2025-08-07 0:03 ` Wilfred Mallawa
2025-07-29 2:41 ` [RFC 2/4] net/tls/tls_sw: use the record size limit specified Wilfred Mallawa
2025-07-29 8:13 ` Damien Le Moal
2025-08-07 0:04 ` Wilfred Mallawa
2025-07-29 2:41 ` [RFC 3/4] nvme/host/tcp: set max record size in the tls context Wilfred Mallawa
2025-07-29 8:16 ` Hannes Reinecke
2025-07-29 2:41 ` [RFC 4/4] nvme/target/tcp: " Wilfred Mallawa
2025-07-29 8:16 ` Hannes Reinecke
2025-07-29 13:37 ` [RFC 0/4] net/tls: add support for the record size limit extension Chuck Lever
2025-08-07 0:14 ` Wilfred Mallawa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=624296dc-69d6-4bdd-bed1-ffcb747fb96d@kernel.org \
--to=dlemoal@kernel.org \
--cc=Dai.Ngo@oracle.com \
--cc=alistair.francis@wdc.com \
--cc=anna@kernel.org \
--cc=axboe@kernel.dk \
--cc=borisp@nvidia.com \
--cc=chuck.lever@oracle.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=donald.hunter@gmail.com \
--cc=edumazet@google.com \
--cc=hch@lst.de \
--cc=horms@kernel.org \
--cc=jlayton@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=kbusch@kernel.org \
--cc=kch@nvidia.com \
--cc=kernel-tls-handshake@lists.linux.dev \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=neil@brown.name \
--cc=netdev@vger.kernel.org \
--cc=okorniev@redhat.com \
--cc=pabeni@redhat.com \
--cc=sagi@grimberg.me \
--cc=tom@talpey.com \
--cc=trondmy@kernel.org \
--cc=wilfred.mallawa@wdc.com \
--cc=wilfred.opensource@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.