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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250901113844.339aa80d@kernel.org>
Date: Mon, 1 Sep 2025 11:39:56 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Wilfred Mallawa <wilfred.opensource@...il.com>
Cc: chuck.lever@...cle.com, kernel-tls-handshake@...ts.linux.dev,
 donald.hunter@...il.com, edumazet@...gle.com, horms@...nel.org,
 hare@...nel.org, john.fastabend@...il.com, linux-kernel@...r.kernel.org,
 netdev@...r.kernel.org, pabeni@...hat.com, wilfred.mallawa@....com, Hannes
 Reinecke <hare@...e.de>
Subject: Re: [PATCH] net/tls: allow limiting maximum record size

On Mon,  1 Sep 2025 15:36:19 +1000 Wilfred Mallawa wrote:
> During a handshake, an endpoint may specify a maximum record size limit.
> Currently, the kernel defaults to TLS_MAX_PAYLOAD_SIZE (16KB) for the
> maximum record size. Meaning that, the outgoing records from the kernel
> can exceed a lower size negotiated during the handshake. In such a case,
> the TLS endpoint must send a fatal "record_overflow" alert [1], and
> thus the record is discarded.
> 
> Upcoming Western Digital NVMe-TCP hardware controllers implement TLS
> support. For these devices, supporting TLS record size negotiation is
> necessary because the maximum TLS record size supported by the controller
> is less than the default 16KB currently used by the kernel.
> 
> This patch adds support for retrieving the negotiated record size limit
> during a handshake, and enforcing it at the TLS layer such that outgoing
> records are no larger than the size negotiated. This patch depends on
> the respective userspace support in tlshd [2] and GnuTLS [3].

I don't get why you are putting this in the handshake handling code.
Add a TLS setsockopt, why any TLS socket can use, whether the socket 
is opened by the kernel or user. GnuTLS can call it directly before 
it returns the socket to kernel ownership.

I feel like I already commented to this effect. If you don't understand
comments from the maintainers - ask for clarifications.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ