docs(linuxkm): document DTLS 1.3 configure flags

[jackctj117]

This pull request adds new documentation to clarify how to enable DTLS 1.3 support in the kernel module build process. The update explains that enabling DTLS 1.3 requires explicit configuration flags and describes the resulting exported symbols.

Documentation improvements:

• Added a new section to linuxkm/README.md explaining that --enable-linuxkm does not automatically enable TLS 1.3 or DTLS, and that enabling DTLS 1.3 requires passing --enable-tls13, --enable-dtls, and --enable-dtls13 to configure. The section also documents the exported DTLS 1.3 kernel symbols.

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #10377

No scan targets match the changed files in this PR. Review skipped.

[Copilot]

Pull request overview

This PR updates the Linux kernel module documentation to clarify how DTLS 1.3 is enabled in linuxkm builds and what DTLS 1.3-related APIs become available to in-kernel consumers.

Changes:

• Added a new linuxkm/README.md section describing the configure flags needed to enable DTLS 1.3.
• Documented that DTLS 1.3-related entry points are exported from libwolfssl.ko for use by other kernel code.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The text says DTLS 1.3 "requires all three flags" to be passed explicitly and points to specific configure.ac line numbers. In configure.ac, --enable-tls13 defaults to enabled (unless overridden, e.g., some FIPS cases), so explicitly passing it is not generally required. Also, hard-coding configure.ac:5634-5636 is brittle as line numbers change; consider referencing the actual configure error message or simply stating that --enable-dtls13 requires both DTLS and TLS 1.3 to be enabled.

Suggested change

	`--enable-linuxkm` does not implicitly enable TLS 1.3 or DTLS, so the DTLS 1.3
	configure check (`configure.ac:5634-5636`) requires all three flags to be
	passed explicitly:
	`--enable-linuxkm` does not implicitly enable TLS 1.3 or DTLS. To enable
	DTLS 1.3 support, `--enable-dtls13` requires both DTLS and TLS 1.3 to be
	enabled, for example:

[Copilot]

The module export mechanism here is EXPORT_SYMBOL_NS_GPL(..., WOLFSSL) (see linuxkm/Kbuild and module_exports.c.template), not plain EXPORT_SYMBOL_GPL. On kernels with symbol namespaces, in-kernel consumers may also need to import the namespace (e.g., MODULE_IMPORT_NS(WOLFSSL)). Consider updating this wording to avoid implying the symbols are exported without a namespace.

Suggested change

	(`wolfDTLSv1_3_client_method`, `wolfDTLSv1_3_server_method`, etc.) as GPL
	kernel symbols, available to other in-kernel consumers via
	`EXPORT_SYMBOL_GPL`.
	(`wolfDTLSv1_3_client_method`, `wolfDTLSv1_3_server_method`, etc.) as
	namespace-qualified GPL kernel symbols via
	`EXPORT_SYMBOL_NS_GPL(..., WOLFSSL)`. On kernels with symbol namespaces,
	other in-kernel consumers may also need to import the `WOLFSSL` namespace,
	for example with `MODULE_IMPORT_NS(WOLFSSL)`.

[Copilot]

For consistency with the earlier README examples, consider prefixing the configure/make commands with a shell prompt ($) and keeping the make -j form consistent (the earlier section uses make -j module). This helps readers copy/paste and visually parse the commands.

Suggested change

	./configure --enable-linuxkm \
	--enable-tls13 --enable-dtls --enable-dtls13 \
	--with-linux-source=/lib/modules/$(uname -r)/build
	make -j$(nproc) module
	$ ./configure --enable-linuxkm \
	--enable-tls13 --enable-dtls --enable-dtls13 \
	--with-linux-source=/lib/modules/$(uname -r)/build
	$ make -j module

[github-actions]

MemBrowse Memory Report

No memory changes detected for:

• gcc-arm-cortex-m4
• gcc-arm-cortex-m4-baremetal
• gcc-arm-cortex-m4-min-ecc
• gcc-arm-cortex-m4-tls12