linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sabrina Dubroca <sd@queasysnail.net>
To: Wilfred Mallawa <wilfred.opensource@gmail.com>,
	Jakub Kicinski <kuba@kernel.org>
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-kselftest@vger.kernel.org, netdev@vger.kernel.org,
	"David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	John Fastabend <john.fastabend@gmail.com>,
	Shuah Khan <shuah@kernel.org>,
	Wilfred Mallawa <wilfred.mallawa@wdc.com>,
	syzbot@syzkaller.appspotmail.com
Subject: Re: [PATCH net-next v6 1/2] net/tls: support setting the maximum payload size
Date: Thu, 16 Oct 2025 00:43:39 +0200	[thread overview]
Message-ID: <aPAjm1tKMKxIdUlj@krikkit> (raw)
In-Reply-To: <20251015015243.72259-2-wilfred.opensource@gmail.com>

2025-10-15, 11:52:43 +1000, Wilfred Mallawa wrote:
> diff --git a/Documentation/networking/tls.rst b/Documentation/networking/tls.rst
> index 36cc7afc2527..dabab17ab84a 100644
> --- a/Documentation/networking/tls.rst
> +++ b/Documentation/networking/tls.rst
> @@ -280,6 +280,17 @@ If the record decrypted turns out to had been padded or is not a data
>  record it will be decrypted again into a kernel buffer without zero copy.
>  Such events are counted in the ``TlsDecryptRetry`` statistic.
>  
> +TLS_TX_MAX_PAYLOAD_LEN
> +~~~~~~~~~~~~~~~~~~~~~~
> +
> +Sets the maximum size for the plaintext of a protected record.
> +
> +When this option is set, the kernel enforces this limit on all transmitted TLS
> +records, ensuring no plaintext fragment exceeds the specified size. This can be
> +used to specify the TLS Record Size Limit [1].

Since this is now "max payload" instead of directly the record size,
we should probably add something to describe how to derive the value
to pass to TLS_TX_MAX_PAYLOAD_LEN from the record size limit:

    For TLS1.2, the record size limit can be used directly.
    For TLS1.3, limit-1 should be passed, as the record size limit
    includes 1B for the ContentType.


And possibly mention that TLS1.3 record padding is currently
unsupported, so whether it should be counted in the value passed via
this setsockopt or not is undecided. (I'm not sure we need to go that
far. Jakub, WDYT?)


[...]
> +static int do_tls_setsockopt_tx_payload_len(struct sock *sk, sockptr_t optval,
> +					    unsigned int optlen)
> +{
> +	struct tls_context *ctx = tls_get_ctx(sk);
> +	struct tls_sw_context_tx *sw_ctx = tls_sw_ctx_tx(ctx);
> +	u16 value;
> +
> +	if (sw_ctx && sw_ctx->open_rec)
> +		return -EBUSY;
> +
> +	if (sockptr_is_null(optval) || optlen != sizeof(value))
> +		return -EINVAL;
> +
> +	if (copy_from_sockptr(&value, optval, sizeof(value)))
> +		return -EFAULT;
> +
> +	if (value < TLS_MIN_RECORD_SIZE_LIM || value > TLS_MAX_PAYLOAD_SIZE)

For 1.3, should we allow TLS_MIN_RECORD_SIZE_LIM-1? The smallest valid
record size limit (according to rfc8449) is 64
(TLS_MIN_RECORD_SIZE_LIM), so after userspace subtracts 1 we would get
TLS_MIN_RECORD_SIZE_LIM-1?

(but this would bring back one "are we 1.2 or 1.3?" check :/)

> +		return -EINVAL;
> +
> +	ctx->tx_max_payload_len = value;
> +
> +	return 0;
> +}

-- 
Sabrina

  parent reply	other threads:[~2025-10-15 22:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-15  1:52 [PATCH net-next v6 1/2] net/tls: support setting the maximum payload size Wilfred Mallawa
2025-10-15  1:52 ` [PATCH net-next v6 2/2] selftests: tls: add tls record_size_limit test Wilfred Mallawa
2025-10-15 22:43 ` Sabrina Dubroca [this message]
2025-10-20  0:00   ` [PATCH net-next v6 1/2] net/tls: support setting the maximum payload size 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=aPAjm1tKMKxIdUlj@krikkit \
    --to=sd@queasysnail.net \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=john.fastabend@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=shuah@kernel.org \
    --cc=syzbot@syzkaller.appspotmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).