Linux Kernel Selftest development
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: "Chuck Lever" <cel@kernel.org>
Cc: "John Fastabend" <john.fastabend@gmail.com>,
	"Sabrina Dubroca" <sd@queasysnail.net>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Simon Horman" <horms@kernel.org>,
	"Shuah Khan" <shuah@kernel.org>,
	netdev@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH net 1/9] net/tls: Bound time spent on no-data records in tls_sw_read_sock()
Date: Mon, 3 Aug 2026 18:19:52 -0700	[thread overview]
Message-ID: <20260803181952.7920e6d0@kernel.org> (raw)
In-Reply-To: <b997d118-0e36-4511-b14e-66704dc8e9c9@app.fastmail.com>

On Mon, 03 Aug 2026 20:35:54 -0400 Chuck Lever wrote:
> On Mon, Aug 3, 2026, at 6:39 PM, Jakub Kicinski wrote:
> > On Sun, 26 Jul 2026 20:33:29 -0400 Chuck Lever wrote:  
> >> +/* Bound the time that consecutive empty ingress data records keep
> >> + * the socket lock held without releasing it.
> >> + */
> >> +#define TLS_RX_NODATA_NS NSEC_PER_MSEC  
> >
> > A time bound is a bad idea in the kernel, a softirq can easily 
> > take >1msec and turn 2 consecutive zero length records into
> > a fatal error for the connection.  
> 
> I don’t have a particular dog in this race, but you and Sabrina need
> to thumb wrestle to decide which way this needs to go. My original
> thought was to use a count of zero-length packets.

There's a time limit on rx_action processing which is super noise prone
on production systems, hence my preference to avoid any time bounds on
in kernel processing.

And looks like user space libs generally put a numeric cap on the
zero-len record count within a batch?

FWIW I'm not super convinced this is actually an issue for TLS 1.3.
DoS generally means that attacker has some leverage but here attacker
has to encrypt the records for real, so I don't really see this as
a DoS vector. But better safe than sorry, I guess.

  reply	other threads:[~2026-08-04  1:19 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-27  0:33 [PATCH net 0/9] net/tls: Receive-path fixes for zero-length data records Chuck Lever
2026-07-27  0:33 ` [PATCH net 1/9] net/tls: Bound time spent on no-data records in tls_sw_read_sock() Chuck Lever
2026-07-30  9:12   ` Sabrina Dubroca
2026-07-30 13:05     ` Chuck Lever
2026-07-30 17:21       ` Sabrina Dubroca
2026-08-07  0:17         ` Chuck Lever
2026-08-03 22:39   ` Jakub Kicinski
2026-08-04  0:35     ` Chuck Lever
2026-08-04  1:19       ` Jakub Kicinski [this message]
2026-07-27  0:33 ` [PATCH net 2/9] net/tls: Consume empty data records in tls_sw_splice_read() Chuck Lever
2026-07-30 10:38   ` Sabrina Dubroca
2026-08-07  0:19     ` Chuck Lever
2026-07-27  0:33 ` [PATCH net 3/9] net/tls: Fail tls_sw_splice_read() after a failed async decrypt Chuck Lever
2026-08-03 22:59   ` Jakub Kicinski
2026-07-27  0:33 ` [PATCH net 4/9] net/tls: Honor O_NONBLOCK in tls_sw_splice_read() Chuck Lever
2026-07-30 10:59   ` Sabrina Dubroca
2026-08-07  0:19     ` Chuck Lever
2026-07-27  0:33 ` [PATCH net 5/9] net/tls: Consume empty data records in tls_sw_recvmsg() Chuck Lever
2026-07-30 12:40   ` Sabrina Dubroca
2026-08-07  0:21     ` Chuck Lever
2026-08-03 22:47   ` Jakub Kicinski
2026-08-07  0:20     ` Chuck Lever
2026-07-27  0:33 ` [PATCH net 6/9] selftests: tls: add peek and splice coverage for zero-length records Chuck Lever
2026-07-27 14:07   ` Sabrina Dubroca
2026-07-27  0:33 ` [PATCH net 7/9] selftests: tls: skip the zero_len tests when TLS is unavailable Chuck Lever
2026-07-27  0:33 ` [PATCH net 8/9] selftests: tls: cover splice on a nonblocking socket Chuck Lever
2026-07-27  0:33 ` [PATCH net 9/9] selftests: tls: cover splice after a failed decrypt Chuck Lever
2026-07-27 15:19   ` Sabrina Dubroca
2026-08-03 22:58 ` [PATCH net 0/9] net/tls: Receive-path fixes for zero-length data records Jakub Kicinski

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=20260803181952.7920e6d0@kernel.org \
    --to=kuba@kernel.org \
    --cc=cel@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=john.fastabend@gmail.com \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sd@queasysnail.net \
    --cc=shuah@kernel.org \
    /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