Skip to content

handshake: support extracting record size limit value #112

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

twilfredo
Copy link

RFC 8449 [1] Section 4 defines the record_size_limit TLS extension, which allows peers to negotiate a maximum plaintext record size during the TLS handshake. The value must be between 64 bytes and 16,384 bytes (2^14). If a TLS endpoint receives a record larger than its advertised limit, it must send a fatal record_overflow alert.

This patch adds support for extracting the record size limit value from the gnutls session and passing it to the kernel. This is to be used by the kernel at the tls layer limit outgoing records to the maximum record size limit as specified by the endpoint.

Based on GnuTLS [2] and Kernel Integration [3].

[1] https://www.rfc-editor.org/rfc/rfc8449#section-4
[2] https://gitlab.com/gnutls/gnutls/-/merge_requests/1989
[3] https://github.com/twilfredo/spdm-linux/commits/wilfred/record-size-tls-test/

RFC 8449 [1] Section 4 defines the record_size_limit TLS extension, which
allows peers to negotiate a maximum plaintext record size during the
TLS handshake. The value must be between 64 bytes and 16,384 bytes (2^14).
If a TLS endpoint receives a record larger than its advertised limit, it
must send a fatal record_overflow alert.

This patch adds support for extracting the record size limit value from
the gnutls session and passing it to the kernel. This is to be used by
the kernel at the tls layer limit outgoing records to the maximum
record size limit as specified by the endpoint.

[1] https://www.rfc-editor.org/rfc/rfc8449#section-4

Signed-off-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
@twilfredo twilfredo force-pushed the wilfred/record-size-ext-upstream branch from e980a14 to e8e6dfc Compare July 21, 2025 03:29
@chucklever
Copy link
Member

This patch adds support for extracting the record size limit value from the gnutls session and passing it to the kernel. This is to be used by the kernel at the tls layer limit outgoing records to the maximum record size limit as specified by the endpoint.

Based on GnuTLS [2] and Kernel Integration [3].

[1] https://www.rfc-editor.org/rfc/rfc8449#section-4
[2] https://gitlab.com/gnutls/gnutls/-/merge_requests/1989
[3] https://github.com/twilfredo/spdm-linux/commits/wilfred/record-size-tls-test/

Two questions:

  • Has [3] been reviewed by netdev@ ?
  • gnutls_record_get_record_size_limit(3) does not appear to exist in some versions of gnuTLS, so an autoconf strategy will be necessary to allow ktls-utils to build on such platforms

@twilfredo
Copy link
Author

This patch adds support for extracting the record size limit value from the gnutls session and passing it to the kernel. This is to be used by the kernel at the tls layer limit outgoing records to the maximum record size limit as specified by the endpoint.
Based on GnuTLS [2] and Kernel Integration [3].
[1] https://www.rfc-editor.org/rfc/rfc8449#section-4
[2] https://gitlab.com/gnutls/gnutls/-/merge_requests/1989
[3] https://github.com/twilfredo/spdm-linux/commits/wilfred/record-size-tls-test/

Two questions:

* Has [3] been reviewed by netdev@ ?

I have not sent out the kernel patches yet, I was waiting to see if the GnuTLS patches can be approved beforehand. Since all of this depends on that.

* gnutls_record_get_record_size_limit(3) does not appear to exist in some versions of gnuTLS, so an autoconf strategy will be necessary to allow ktls-utils to build on such platforms

Ah I see, I will add that. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants