Correct reassembly logic in sniffer. Fix handshake message size in BuildCertificateStatus. Ensure MTU is set properly when using SCTP with DTLS. Improve SCTP examples.
bench_gmac_internal() passed a literal 0 as useDeviceID to
bench_stats_sym_finish(), so with BENCH_DEVID defined both the software and the
hardware run printed "SW", and bench_stats_add() merged them into one entry
because it keys on that value too. On an accelerator where GMAC goes from
146 KiB/s to 8.7 MiB/s the mislabelling is easy to spot, but the table said the
two were the same measurement.
WOLF_CRYPTO_CB reached a Kconfig-driven build only through wolfTPM, so an
application with a crypto device of its own had no way to enable the
callback interface, and no way to reach WOLF_PRIVATE_KEY_ID with it - which
is what lets a TLS private key stay on that device rather than sit in the
application's memory.
A port that brings its own device should keep defining WOLF_CRYPTO_CB from
its own option rather than selecting this one: a select reaches a
settings-file build, where the settings file is authoritative over anything
that changes struct layouts.
Nothing in the module exposed HAVE_OCSP or the certificate status request
extension, so a Kconfig-driven build had no way to ask a TLS server to
staple an OCSP response for its own certificate. Both stay off by default.
WOLFSSL_MAX_FRAGMENT_LEN served two masters. Its presence gated
HAVE_MAX_FRAGMENT in the module's user_settings.h, where the value was never
read, while the value itself was passed straight to
wolfSSL_CTX_UseMaxFragment() by Zephyr's sockets_tls.c. Gating it on the
settings file, as the commit that introduced that dependency did, is right for
the first role and silently kills the second: an application supplying its own
settings file loses max fragment length negotiation with no way to ask for it
back.
Split the two. The module keeps a bool, WOLFSSL_MAX_FRAGMENT, doing the one
thing it ever did, and the length moves to Zephyr's socket layer as
NET_SOCKETS_TLS_WOLFSSL_MAX_FRAGMENT_LENGTH, in bytes, alongside the mbedTLS
equivalent it already keeps there. sockets_tls.c then gates the call on
HAVE_MAX_FRAGMENT rather than on a CONFIG_ symbol, so it works whichever way
wolfCrypt was configured.
The old symbol was an index into the WOLFSSL_MFL_* enum despite its name, so
WOLFSSL_MAX_FRAGMENT_LEN=3 meant 2048 bytes, and its values 5 and 6 selected
the 8192 and 256 byte codes wolfSSL defines outside RFC 6066. Renaming rather
than repurposing it means a build setting the old option fails on an undefined
Kconfig symbol instead of quietly changing meaning.
wc_keystore.c arrived with the WC_ALGO_TYPE_KEYSTORE callback API and the
module's source list never gained it, so a Zephyr build that sets
WOLF_CRYPTO_CB_KEYSTORE compiles the header and links against nothing. The
file is guarded on that macro, so listing it costs the other configurations
an empty object.
Four options guarded the assembly - WOLFCRYPT_ARMASM, its THUMB2 companion,
WOLFCRYPT_INTELASM, and nothing at all for the single-precision math - and
between them they could not express a working configuration on any target.
WOLFCRYPT_ARMASM_THUMB2 selected the thumb2 sources but nothing defined
WOLFSSL_ARMASM_THUMB2, so the link failed on AES_*_AARCH32. WOLFCRYPT_INTELASM
named the 32-bit sources while user_settings.h declared WOLFSSL_X86_64_BUILD,
so aes_asm.S compiled to an empty object and aes_gcm_x86_asm.S emitted 32-bit
code into a 64-bit build.
Only one combination is ever right for a given board, so the four collapse
into WOLFCRYPT_ASM and the module derives the rest from the CPU Zephyr
reports. ARMv6-M and ARMv8-M baseline get no symmetric assembly - the Thumb2
port uses UBFX and LDRD, which those cores do not have - and keep the Thumb
math.
Each ARM port sets two single-precision macros. WOLFSSL_SP_<cpu>_ASM compiles
the per-size backend; the unsuffixed WOLFSSL_SP_<cpu> enables the inline-asm
word primitives in sp_int.c, which is what the generic WOLFSSL_SP_MATH_ALL
path uses for every other size and curve. Defining only the _ASM half, as this
module did, left Brainpool, custom curves and any uncovered RSA or DH size
with no assembly at all.
Every ARM profile needs WOLFSSL_ARMASM_NO_HW_CRYPTO unless the toolchain says
otherwise. The ARMv8-32 sources carry no .arch_extension, so a plain ARMv7
part rejects aese.8 outright; the AArch64 ones do carry it and always
assemble, which moves the failure rather than removing it, since cpuid.c has
no ID registers to read here and reports AES, PMULL and SHA-256 present
whenever the macro is unset. Key it on __ARM_FEATURE_CRYPTO, and the ARMv8.1
RDMA opt-out on __ARM_FEATURE_QRDMX for the same reason.
ML-KEM's small-memory key generation and encapsulation are dropped where the
assembly is on for x86_64 or AArch64: wc_mlkem.c rejects that combination with
an #error rather than falling back.
Neither 32-bit x86 nor the x86_64 single-precision assembly is offered. The
latter is worth recording: sp_x86_64_asm.S is AVX throughout and sp_x86_64.c
calls into it with no CPUID dispatch and no scalar counterpart, while Zephyr
never sets CR4.OSXSAVE, so those instructions fault.
Both set(TOOLCHAIN_C_FLAGS ...) calls go: Zephyr applies that variable
globally before it add_subdirectory's modules, so the assignment ran after the
flags were consumed and never reached the parent scope either.
HAVE___UINT128_T is defined wherever the compiler has the type, since with
user settings nobody sets it and sp_int.c fails on an undeclared sp_int_word.
One wolfssl_test scenario per port covers the option: qemu_x86_64 for Intel,
qemu_cortex_a53 for AArch64, and mps2/an521/cpu0 for Thumb2. AArch64 gets a
second at -mcpu=cortex-a53+crypto, since the guard above keeps the hardware
blocks out of the first and the .arch_extension directives would otherwise
never be assembled here.
Measured on frdm_rw612, ops/sec: ECDSA P-256 sign 16 to 136, verify 10 to 102,
RSA-2048 public 86 to 194.
Kconfig.tls-generic is a copy of Zephyr's mbedTLS file with the symbol prefix
renamed, which is why a wolfSSL module carries options named after mbedTLS
internals. Renaming was all that happened: of its 53 config symbols, exactly
two reach any code, WOLFSSL_TLS_VERSION_1_2 and _1_3. Checked every symbol
against the whole workspace; the other 51 appear only in that file, so
CONFIG_WOLFSSL_ECP_DP_SECP384R1_ENABLED=y has always done nothing.
Three are worse than inert: WOLFSSL_TLS_VERSION_1_0, _1_1 and _1_3 select
symbols that are defined nowhere, and Kconfig accepts that silently, so the
reader sees a mechanism that does not exist.
Delete the file and move the two live symbols into the module's own Kconfig,
next to WOLFSSL_DTLS, keeping the settings-file dependency. The dead selects
go with it, as do four dead options the TLS samples were setting and a stale
entry in .wolfssl_known_macro_extras.
TLS 1.3 gains a default of y. The old file had 1.2 on and 1.3 off, Zephyr's
mbedTLS default from 2018, while wolfSSL's own configure enables both. Keeping
1.2 as well preserves interop with the TLS 1.2-only peers embedded deployments
still meet; a 1.3-only build works by clearing the 1.2 option.
That default is also what first reached DefTicketEncCb(), hence the wolfio
byte-order fix earlier in this branch.
The build-profile options only write the module's user_settings.h, which is
never read when the application supplies its own settings file. So
CONFIG_WOLFSSL_ECC_384=y alongside a settings file was accepted and silently
ignored, as was every other feature option.
They now depend on not having one. This needs a tracking bool, because
WOLFSSL_SETTINGS_FILE is a string symbol and Kconfig evaluates a string in a
logical context as always-false, which would have made every one of these
dependencies quietly unsatisfiable.
FIPS is gated on the master switch rather than each version: on the choice
members alone the version prompt would stay visible with nothing selectable,
while CMake still compiled the FIPS bundle.
Kconfig.tls-generic is left alone here - only two of its 53 symbols reach any
code, so gating the rest would make dead options look conditional, and the
commit after this one deletes it. Options that drive the build rather than the
wolfCrypt configuration stay selectable either way.
The curve Kconfigs decide which curves wolfCrypt compiles and which SP
implementation backs them, and getting that pairing wrong fails at runtime
with WC_KEY_SIZE_E rather than at build time. Two wolfssl_test scenarios pin
the combinations that matter: the NIST curves on their per-curve SP paths, and
the Brainpool set that forces the generic backend, with no P-521 present to
lend it a curve ceiling.
The module hard-coded ECC_USER_CURVES with SECP256R1 alone, so an application
needing P-384, P-521 or Brainpool had to patch user_settings.h. Each curve is
now its own option under WOLFSSL_ECC, with P-256 the default so existing
configurations are unaffected.
Two dependencies are encoded rather than left to be rediscovered, since both
fail without pointing at the cause. Brainpool needs WOLFSSL_CUSTOM_CURVES, its
curves not being prime-field NIST ones; custom curves in turn cannot coexist
with the per-curve SP math this module selects, so asking for Brainpool moves
the build onto the generic SP variant. That costs size and speed on the common
curves, which is why it is opt-in.
Brainpool does not drag another curve in with it, though it looks as though it
must: on the generic variant the enabled-curve ceiling has to clear the largest
Brainpool curve compiled in, and when it does not that curve fails with
WC_KEY_SIZE_E. That ceiling was short by one bit, fixed earlier in this branch.
Koblitz keeps its commented-out line rather than gaining an option, secp256k1
and secp224k1 having no TLS or wolfPSA use. P-256 keeps its inverted sense,
being the one curve wolfCrypt enables by default.
Verified on frdm_rw612: with P-384 and P-521 selected all three curves
round-trip a signature on device; with the defaults the image is unchanged and
20 KB smaller.
XHTONS and XNTOHS resolve to htons() and ntohs() when the socket I/O layer is
compiled in. Zephyr 4.4 renamed those to net_htons() and net_ntohs(), and
brings the unprefixed spellings back only under
CONFIG_NET_NAMESPACE_COMPAT_MODE:
wolfio.h:1060: error: implicit declaration of function 'htons'
On a host-libc target such as native_sim it surfaces at link time instead, out
of DefTicketEncCb(). That call site uses XHTONS on a session-ticket length
field rather than on a socket port, so the macro is doing plain byte-order
work; nothing had reached it before because session tickets require TLS 1.3.
Zephyr 4.3 and older define the unprefixed names themselves, so neither
spelling covers the supported range. Gate on KERNEL_VERSION_NUMBER, the way
the 4.1 socket changes already are a few hundred lines above.
A WOLFSSL_CUSTOM_CURVES build fails at runtime on its own largest enabled
curve:
ecc_test_curve_size 64 failed! (WC_KEY_SIZE_E, -234)
Not a Brainpool quirk - a bp256-only build fails on bp256, bp256+bp384 on
bp384. The ceiling is off by exactly one bit: ECC_KEY_MAX_BITS() takes a
"dp->size * 8 + 1" variant for orders a bit larger than their prime, while
MAX_ECC_BITS_NEEDED is the plain curve size, and MP_BITS_CNT() rounds up to
whole digits, so that bit puts the key one digit past the ceiling.
Name it MAX_ECC_BITS_EXTRA and build both sides from it. Custom curves are
only one of three ways the variant gets selected: ECC_MIN_KEY_SZ at or below
160 takes it, as does HAVE_ECC_KOBLITZ at or below 224, the default for any
Koblitz build. MAX_ECC_BITS keeps meaning the plain size of the largest curve,
so a build that pins it to exactly what its curves need still passes the guard
that rejects a too-small value.
MAX_ECC_BITS_USE also derived from MAX_ECC_BITS_NEEDED, so an overridden
MAX_ECC_BITS never reached the runtime guard. Derive it from MAX_ECC_BITS,
which only ever widens, and is what an arbitrary curve passed to
wc_ecc_set_custom_curve() needs. The SP_INT_BITS clamp above it is unchanged.
Raising the ceiling reaches a latent overflow behind it. The curves the extra
bit exists for have an order a byte longer than their prime, and
wc_ecc_gen_deterministic_k() sizes x and h1 with MAX_ECC_BYTES, which comes
from the prime, then writes mp_unsigned_bin_size(order) bytes into them. On
secp160r1 that is 21 bytes into 20, the last of them the low byte of the
private scalar. It is not new here - ASAN reports it on the merge base at
64-bit digits, where MP_BITS_CNT() rounds 160 and 161 to the same count - but
at 32-bit digits the old ceiling rejected the curve at wc_ecc_make_key()
before signing could reach it, so this commit is what makes it reachable.
Size those buffers from the order with MAX_ECC_ORDER_BYTES, and reject an
order larger than that. The macro is never smaller than MAX_ECC_BYTES, and
only larger when MAX_ECC_BITS is a multiple of 8 and the extra bit applies, so
a P-521 build stays at 66 bytes.
L_mlkem_aarch64_consts sat outside the WOLFSSL_HAVE_MLKEM conditional while
zetas, zetas_inv and q sat inside it. With ML-KEM off the C output declares a
static const nothing references:
armv8-mlkem-asm_c.c:37: error: 'L_mlkem_aarch64_consts' defined but not used
[-Werror=unused-const-variable=]
Zephyr compiles with -Werror, so armv8-mlkem-asm_c.c was unbuildable on any
aarch64 target without ML-KEM, which is every one by default.
The cause is in the generator: initialize() emitted the constant but write()
is what opens the guard and runs later. Fixed there with a define_consts()
called from write(), mirroring the existing define_q(); these files are the
regenerated result.
The ARM64 ML-KEM port emits eor3, which is not in the base ARMv8-A a toolchain
may be invoked with, and the file carries no directive:
armv8-mlkem-asm.S: Error: selected processor does not support
`eor3 v31.16b,v0.16b,v5.16b,v10.16b'
The directive sits inside WOLFSSL_ARMASM_CRYPTO_SHA3, the guard selecting the
variant that needs it, so a build that has not opted in never asks for it.
The same file's sqrdmlsh deliberately gets none. RDMA is opt-out
(WOLFSSL_AARCH64_NO_SQRDMLSH) where SHA-3 is opt-in, and on a target with no
way to read the ID registers cpuid.c reports it present whenever that macro is
unset. A directive there would turn a build the assembler correctly rejects
into an image that traps on the first sqrdmlsh, so the mnemonic is left to
answer to -mcpu.
The SHA-3, SHA-512 and FrodoKEM ARM64 ports guard their .arch_extension sha3
with __APPLE__, assuming every other assembler learns the extension from the
command line. It does not hold:
armv8-sha3-asm.S: Error: selected processor does not support
`eor3 v31.16b,v0.16b,v5.16b,v10.16b'
Emit it unconditionally; it is a no-op where the extension is already on, so
the Apple path is unchanged. The AES port needs it too and had none: its
AES-GCM EOR3 variants emit eor3, while the only directive in the file is the
crypto one added earlier in this branch, which does not cover sha3.
Regenerated from the scripts repository, which carries the matching change.
The ARMv8 AES and SHA-256 ports emit aese, aesmc and the sha256 instructions
with no directive of their own, so they assemble only when the command line
already names a CPU that has the extension:
armv8-aes-asm.S: Error: selected processor does not support
`aese v0.16b,v1.16b'
Zephyr lands there: it derives -mcpu from the board and has no symbol for the
extension, and naming a CPU in the module would retarget every other board.
Add .arch_extension crypto. The .S and .asm outputs carry one at file scope;
the C output cannot, because clang gives each __asm__ block a fresh subtarget,
so there it leads every block, as the SHA-3 ports already do.
All three sit inside WOLFSSL_ARMASM_NO_HW_CRYPTO, and that guard now carries
the whole safety argument, which is the part worth recording. The directive
removes the assembler's refusal, so setting the macro becomes the integrator's
job rather than something the toolchain enforces: with no ID registers to
read, cpuid.c reports AES, PMULL and SHA-256 present whenever it is unset, and
a base-ARMv8 build then dispatches them on a core where FEAT_AES is optional.
FrodoKEM's aese deliberately gets no directive for the same reason - it has no
such guard to opt out through.
Regenerated from the scripts repository, which carries the matching change.
CPUID's AVX and AVX-512 bits say the silicon has the unit. Executing those
instructions also needs the OS to have enabled extended state - CR4.OSXSAVE
plus the matching XCR0 components - and an OS that does not context-switch
those registers leaves them clear, so the instruction raises #UD whatever
CPUID says. cpuid_set_flags() tested the feature bits alone. Zephyr is such a
system: its x86 context switch is fxsave/fxrstor and it never sets
CR4.OSXSAVE, so the first vector SHA-256 or AES-GCM path crashes.
Gate each family on OSXSAVE plus the XCR0 components it needs, in the order
Intel documents - XGETBV is only legal once OSXSAVE is set. The masks have to
differ because the AVX-512 dispatch sites branch on IS_INTEL_AVX512 &&
IS_INTEL_VAES without consulting AVX1 or AVX2, so gating only the 256-bit
flags would leave the 512-bit paths reachable on exactly the systems this
protects.
Nothing changes where an OS enables XSAVE, which is every mainstream one.
The nine div-word helpers bind a variable to rax with the bare asm keyword,
which is a GNU extension rather than an ISO C one and so is unavailable under
-std=c17:
sp_x86_64.c:597: error: expected '=', ',', ';', 'asm' or '__attribute__'
before 'asm'
Zephyr compiles with -std=c17, but any strict-ISO build hits it. __asm__ is
the spelling GCC and Clang keep regardless of -std, and is what the next line
of each function already uses.
The WOLFSSL_ZEPHYR block includes <zephyr/kernel.h> and friends and declares
z_realloc. Assembly reaches settings.h through libwolfssl_sources_asm.h, so
the assembler got all of it and stopped at the first C declaration:
stddef.h:160: Error: no such instruction: `typedef long int ptrdiff_t'
That makes every wolfSSL .S file unbuildable on Zephyr, on any architecture -
reproduced on x86_64 and on a Cortex-M33. Ports using the *_c.c inline
variants never noticed, since those are compiled as C.
Guard the block with __ASSEMBLER__, as settings.h already does for the
STM32MP13 header. No effect on any C translation unit.
WOLFSSL_ARM_ARCH_7M selects the UMAAL-free variants in sp_cortexm.c and the
thumb2 assembly, but was derived from __ARM_ARCH_7M__, which names the
Cortex-M3 alone. UMAAL belongs to the DSP extension, optional on ARMv8-M, so a
part like the Cortex-M33 in the NXP RW612 has neither UMAAL nor
__ARM_ARCH_7M__ and took the UMAAL path anyway.
Key on the absence of __ARM_FEATURE_DSP, which toolchains define exactly when
the extension is present. Verified with gcc for M0, M3, M4, M7, M23, M33 and
M33+nodsp. The __ARM_ARCH_7M__ arm stays, so nothing that worked before
changes.
Zephyr 4.1 removed CONFIG_NET_SOCKETS_POSIX_NAMES, so settings.h took over the
job itself and defined socket, bind, connect, listen, accept, send, recv,
sendto, recvfrom, setsockopt, getsockopt, shutdown, getpeername and getsockname
as object-like macros onto their zsock_ counterparts.
settings.h is reached from every wolfSSL header, so those macros rewrite any
matching token in any translation unit that includes one - including members of
structures that have nothing to do with wolfSSL. Zephyr's own
struct socket_op_vtable declares bind, connect, listen, accept, shutdown,
sendto, recvfrom, getsockopt and setsockopt, and whether a file compiles at all
comes down to the order of its includes:
#include <zephyr/net/socket.h> /* members declared without the macros */
#include <wolfssl/ssl.h> /* macros arrive */
static const struct socket_op_vtable vt = { .bind = my_bind };
error: 'const struct socket_op_vtable' has no member named 'zsock_bind'
The compiler then drops the designated initializer and falls back to positional
initialization, so the handler is installed in the wrong slot. Reversing the two
includes builds cleanly. Zephyr's own TLS socket layer hits this and carries a
block of #undefs to defuse it.
Call Zephyr's API by its own name instead. send/recv already go through
SEND_FUNCTION/RECV_FUNCTION and sendto/recvfrom through
DTLS_SENDTO_FUNCTION/DTLS_RECVFROM_FUNCTION, so those only needed a value;
socket and accept run through wc_socket_cloexec()/wc_accept_cloexec(); close and
inet_pton/inet_ntop were already handled by CloseSocket and XINET_PTON/XINET_NTOP.
That leaves bind, connect, listen, getsockopt, setsockopt and getpeername, which
get XSOCKET_* wrappers in wolfio.h. They default to the BSD names, so every other
port preprocesses exactly as before.
zsock_ is also the only spelling that works across configurations from 4.4 on:
the POSIX aliases in <zephyr/posix/sys/socket.h> need
CONFIG_NET_NAMESPACE_COMPAT_MODE, and CONFIG_NET_NAMESPACE_COMPAT_MODE itself
only restores types and constants, never the function names.
wolfssl/test.h keeps a remapping of its own, placed after its system includes
where no later declaration can be caught by it, since the harness calls the
socket API directly in many more places.
David Garske
JacobBarthelmeh
Aidan Garske
jordan
Kareem
Eric Blankenhorn
Tobias Frauenschläger