Hey Chuck, On Tue, 2025-07-29 at 09:37 -0400, Chuck Lever wrote: > Hi Wilfred - > > On 7/28/25 10:41 PM, Wilfred Mallawa wrote: > > From: Wilfred Mallawa <wilfred.mallawa@xxxxxxx> > > > > During a tls handshake, an endpoint may specify a maximum record > > size limit. As > > specified by [1]. which allows peers to negotiate a maximum > > plaintext record > > size during the TLS handshake. If a TLS endpoint receives a record > > larger > > than its advertised limit, it must send a fatal "record_overflow" > > alert [1]. > > Currently, this limit is not visble to the kernel, particularly in > > the case > > where userspace handles the handshake (tlshd/gnutls). > > This paragraph essentially says "The spec says we can, so I'm > implementing it". Generally we don't implement spec features just > because they are there. > > What we reviewers need instead is a problem statement. What is not > working for you, and why is this the best way to solve it? Thanks for the feedback. Essentially, this is to support upcoming WD NVMe-TCP controller that implements TLS support. These devices require record size negotiation as they support a maximum record size less than the current kernel default. I will add this to my V2 series in more detail. > > > > This series in conjunction with the respective userspace changes > > for tlshd [2] > > and gnutls [3], adds support for the kernel the receive the > > negotiated record > > size limit through the existing netlink communication layer, and > > use this > > value to limit outgoing records to the size specified. > > As Hannes asked elsewhere, why is it up to the TLS consumer to be > aware of this limit? Given the description here, it sounds to me > like something that should be handled for all consumers by the TLS > layer. Yeah great point, I didn't think it through too well. I will address this in V2 and have the record size limit implemented in the TLS layer without involving ULPs. Regards, Wilfred
