Zephyr fixes - #11401
Open
Frauschi wants to merge 14 commits into
Open
Conversation
…x-M3 WOLFSSL_ARM_ARCH_7M selects the UMAAL-free variants in sp_cortexm.c and in the thumb2-* assembly for Poly1305, Curve25519 and ML-KEM. It was derived from __ARM_ARCH_7M__, which names the Cortex-M3 and nothing else. UMAAL is not an ARMv7-M property though, it belongs to the DSP extension, which on ARMv8-M is optional. An ARMv8-M part built without it, such as the Cortex-M33 in the NXP RW612, has no UMAAL and no __ARM_ARCH_7M__ either, so it took the UMAAL path and would not assemble. WOLFSSL_SP_NO_UMAAL is not a way out: it is derived from this symbol and covers only a subset of the sites. Toolchains define __ARM_FEATURE_DSP exactly when the extension is present, so key on its absence on an M-profile core. Verified against gcc for M0, M3, M4, M7, M23, M33 and M33+nodsp: it is set only where UMAAL is genuinely missing. The __ARM_ARCH_7M__ arm stays, so no configuration that worked before changes, and the __ARM_ARCH_PROFILE test matches the one already in cpuid.c.
The WOLFSSL_ZEPHYR block includes <zephyr/kernel.h>, <zephyr/sys/printk.h>, <zephyr/sys/util.h> and <stdlib.h>, and declares z_realloc. Assembly sources reach settings.h through libwolfssl_sources_asm.h, so all of that was being handed to the assembler, which stops at the first C declaration it meets: stddef.h:160: Error: no such instruction: `typedef long int ptrdiff_t' That makes every wolfSSL .S file unbuildable on Zephyr. It is not specific to one architecture or one algorithm - reproduced on x86_64 with chacha_asm.S, sha256_asm.S, sha512_asm.S and aes_asm.S, and on a Cortex-M33 with thumb2-aes-asm.S, which fails identically: stddef.h:160: Error: bad instruction `typedef int ptrdiff_t' Zephyr ports that use the *_c.c inline-assembly variants never noticed, because those are compiled as C. Guard the block with __ASSEMBLER__, matching what settings.h already does for the STM32MP13 header. Assembly still gets the feature macros from user_settings.h; it just no longer gets the C declarations. No effect on any C translation unit - __ASSEMBLER__ is only defined when the compiler driver is assembling.
…s them
The nine div-word helpers bind a variable to rax with the bare asm keyword:
register sp_digit r asm("rax");
asm is a GNU extension, not an ISO C keyword, so it is unavailable under
-std=c17 and the file will not compile:
sp_x86_64.c:597: error: expected '=', ',', ';', 'asm' or '__attribute__'
before 'asm'
Zephyr compiles with -std=c17, which is how this surfaced, but any strict-ISO
build hits it. __asm__ is the alternate spelling GCC and Clang keep available
regardless of -std, and it is what the very next line of each of these
functions already uses for the statement asm - so this only makes the two
consistent.
CPUID's AVX and AVX-512 bits say the silicon has the unit. Executing one of those instructions also requires the OS to have turned on extended state: CR4.OSXSAVE, plus the matching XCR0 components - SSE and AVX for VEX encodings, and opmask, ZMM_Hi256 and Hi16_ZMM on top of those for EVEX. An OS that does not context-switch those registers leaves them clear, and the instruction then raises #UD no matter what CPUID advertises. cpuid_set_flags() tested the feature bits alone, so on such a system wolfSSL set CPUID_AVX1/AVX2/VAES/AVX512* and dispatched to implementations the CPU would refuse. Zephyr is one such system - its x86 context switch is fxsave/fxrstor and it never sets CR4.OSXSAVE - and the result is an immediate crash the first time SHA-256 or AES-GCM picks a vector path: <err> os: Invalid opcode >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0 Gate each family on OSXSAVE plus the XCR0 components it actually needs, the sequence Intel documents for this. The AVX-512 dispatch sites are the reason the masks have to differ: AesEcbEncryptBlocks(), AES_GCM_init_*, chacha_avx512_beneficial() and poly1305_use_avx512() all 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 is meant to protect. Keeping them on one gate would also be wrong in the other direction, since 0x06 does not cover the ZMM state. VAES is VEX or EVEX encoded, so it is gated with the AVX state; the AVX-512 dispatch sites test it alongside CPUID_AVX512, which carries the stricter mask. Where an OS does enable XSAVE, which is every mainstream one, nothing changes. XGETBV is itself only legal once OSXSAVE is set, so the two tests have to stay in that order.
The ARMv8 AES and SHA-256 ports emit aese, aesmc and the sha256 crypto
instructions with no .arch or .arch_extension directive of their own, so they
assemble only when the command line already names a CPU that has the
extension. Built against plain ARMv8-A, which is what -mcpu=cortex-a53 gives
you, the assembler refuses them:
armv8-aes-asm.S: Error: selected processor does not support
`aese v0.16b,v1.16b'
Zephyr is one caller that lands there. It derives -mcpu from the board's
Kconfig and has no symbol for the crypto extension, so there is nothing for a
build system layered on top to key on, and naming a CPU in the module would
retarget the library on every board that is not that CPU. Anything else
compiling for the base architecture meets the same wall.
A file-scope .arch_extension crypto applies to the rest of the translation
unit, so one directive per file does what would otherwise take sixty inline
copies. All three outputs carry it - bare in the GNU assembler file, wrapped
in __asm__() in the C file, and a comment in the armasm64 file, which
assembles these instructions unconditionally. Each sits inside the existing
WOLFSSL_ARMASM_NO_HW_CRYPTO guard, so a build that has opted out of the
hardware paths never asks for an extension it will not use.
Regenerated from the scripts repository, which carries the matching change.
Verified on qemu_cortex_a53 under Zephyr: wolfcrypt_test passes 43 of 43 with
2723 aese instructions in the image, where before neither file assembled.
The SHA-3, SHA-512 and FrodoKEM ARM64 ports guard their .arch_extension sha3
with __APPLE__, on the assumption that every other assembler learns about the
extension from the command line. That does not hold. Assembling for plain
ARMv8-A with the GNU assembler:
armv8-sha3-asm.S: Error: selected processor does not support
`eor3 v31.16b,v0.16b,v5.16b,v10.16b'
Emit the directive unconditionally. It is a no-op where the extension is
already enabled, so the Apple path is unchanged.
Regenerated from the scripts repository, which carries the matching change.
L_mlkem_aarch64_consts sat outside the WOLFSSL_HAVE_MLKEM conditional while
every other constant in the file - zetas, zetas_inv, q - sat inside it. With
ML-KEM off the C output then declares a static const nothing references, and a
-Werror build stops:
armv8-mlkem-asm_c.c:37: error: 'L_mlkem_aarch64_consts' defined but not used
[-Werror=unused-const-variable=]
Zephyr compiles wolfSSL with -Werror, so this made armv8-mlkem-asm_c.c
unbuildable on any aarch64 target that does not enable ML-KEM - which is every
one of them by default.
The cause is in the generator: Kyber_ARM64_Neon_ASM#initialize emitted the
constant, but write() is what opens the guard, and it runs later. Fixed there by
moving the emission into a define_consts() called from write(), mirroring the
existing define_q(); these files are the regenerated result. All three outputs
change by the same three-line move and nothing else.
A WOLFSSL_CUSTOM_CURVES build fails at runtime on its own largest enabled curve. Enabling Brainpool with sizes 256, 384 and 512 gives ecc_test_curve_size 64 failed! (WC_KEY_SIZE_E, -234) and it is not a bp512 quirk: a bp256-only build fails on bp256, a bp256+bp384 build on bp384. Every time it is the largest curve in the set. The ceiling is off by exactly one bit. Under custom curves ECC_KEY_MAX_BITS() takes the "dp->size * 8 + 1" variant, for orders a bit larger than their prime, but MAX_ECC_BITS_NEEDED is the plain curve size. MP_BITS_CNT() rounds up to whole digits, so that single bit puts the key one digit past the ceiling and MP_BITS_OVER_MAX() rejects it. Carry the same bit in the ceiling via MAX_ECC_BITS_EXTRA, and compare against it in the guard that rejects a too-small user MAX_ECC_BITS. Second, MAX_ECC_BITS_USE derived from MAX_ECC_BITS_NEEDED, so the overridable MAX_ECC_BITS never reached the runtime guard - defining it larger changed the key struct but not the check, and there was no way to size the working values for a curve that is not compiled in. Derive it from MAX_ECC_BITS instead; ecc.h already refuses a value below what the enabled curves need, so this only ever widens, and it is what an arbitrary curve passed to wc_ecc_set_custom_curve() needs. Both are no-ops for a build without custom curves.
XHTONS and XNTOHS resolve to htons() and ntohs() whenever the socket I/O
layer is compiled in. On Zephyr those two are POSIX aliases that only exist
under CONFIG_POSIX_API, where <zephyr/posix/arpa/inet.h> defines them in
terms of net_htons(). A networking build without that option fails to
compile the moment anything reaches them:
wolfio.h:1060: error: implicit declaration of function 'htons'
[-Wimplicit-function-declaration]
The call site is DefTicketEncCb() in internal.c, which uses XHTONS on a
session-ticket length field rather than on a socket port - so the macro is
doing plain byte-order work and has no business needing the socket API at
all. Nothing had reached it before because session tickets require TLS 1.3.
net_htons() and net_ntohs() are the native spelling and are always present:
they are sys_cpu_to_be16 and sys_be16_to_cpu macros from
<zephyr/net/net_ip.h>, which arrives with the <zephyr/net/socket.h> this
header already includes unconditionally for Zephyr. Use them there, matching
the Zephyr branch XINET_PTON carries a few lines above for the same reason.
Reproduced on Zephyr's own net.http.server.tls.wolfssl, which enables
networking but not CONFIG_POSIX_API; it and the other seven wolfssl-tagged
scenarios pass with this.
The module hard-coded ECC_USER_CURVES with SECP256R1 and nothing else, so an application needing P-384, P-521 or a Brainpool curve had to patch user_settings.h. Each curve is now its own Kconfig option under WOLFSSL_ECC, with P-256 the default so existing configurations are unaffected. Two dependencies are encoded here rather than left for the next person to hit, because both fail in a way that does not point at the cause. Brainpool needs custom-curve support. Its curves are not prime-field NIST curves, and ecc.c refuses to build them without WOLFSSL_CUSTOM_CURVES. Custom curves in turn cannot coexist with the per-curve SP math this module selects, because SP's fast paths are written per curve and cannot represent an arbitrary one. Asking for Brainpool therefore moves the whole build onto the generic SP variant, which costs size and costs speed on the common curves. That is a real trade-off, and it is why Brainpool 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 at runtime with WC_KEY_SIZE_E. Measured on native_sim: brainpoolP256r1 failed with a 256-bit ceiling, brainpoolP384r1 with a 384-bit one and brainpoolP512r1 with a 512-bit one - each time the largest curve in the set. That ceiling was short by exactly one bit, fixed earlier in this branch, so a Brainpool build compiles only the sizes it asks for. Koblitz keeps its commented-out HAVE_ECC_KOBLITZ line rather than gaining an option. secp256k1 and secp224k1 have no TLS use and no wolfPSA one, so the hand-edit hint is the right level of support for them. P-256 keeps its inverted sense: it is the one curve wolfCrypt enables by default, so it is turned off by defining NO_ECC256 rather than by omission. Verified on frdm_rw612. With P-384 and P-521 selected, all three curves generate a key and round-trip a signature on device; with the defaults the image is unchanged at P-256 only and 20 KB smaller, since neither the extra curves nor the generic math are pulled in.
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 with no custom curve in sight, and the Brainpool set that forces the generic backend, with no P-521 present to lend it a curve ceiling.
…s used 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, and the same went for every other feature option. They now depend on not having one, and disappear from the menu instead. 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 on each version. WOLFCRYPT_FIPS writes HAVE_FIPS into user_settings.h, so it belongs under the rule; putting the dependency on the choice members alone would leave the version prompt visible with nothing selectable and its default unreachable, 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; the commit after this one deletes the file and rehomes those two with the dependency. wolfssl_tls_sock's no-malloc scenario was setting five of those options next to a settings file, so they now name symbols that are not visible. Drop them and say why they are gone. Options that drive the build rather than the wolfCrypt configuration, meaning the implementation choice, the assembly port and the install path, are untouched and stay selectable either way.
Kconfig.tls-generic is a copy of Zephyr's mbedTLS Kconfig.tls-generic with the symbol prefix renamed, which is why a wolfSSL module carries options named after mbedTLS internals - ECP is their elliptic-curve-over-prime-field module and DP their domain parameters, neither of which means anything here. Renaming the prefix was all that happened: nothing was wired up behind it. Of the 53 config symbols in the file, exactly two reach any code, WOLFSSL_TLS_VERSION_1_2 and _1_3. Checked every symbol against the whole workspace - all .c, .h, .cmake, CMakeLists.txt, Kconfig and .conf files under zephyr/ and modules/crypto/wolfssl. The other 51 appear only in that file. Setting CONFIG_WOLFSSL_ECP_DP_SECP384R1_ENABLED=y has always done precisely nothing, and unlike the options the previous commit gated, these do nothing whether or not a settings file is present. Three of them are worse than inert. WOLFSSL_TLS_VERSION_1_0, _1_1 and _1_3 select WOLFSSL_ALLOW_TLSV10_ENABLED, WOLFSSL_NO_OLD_TLS_DISABLED and WOLFSSL_TLS13_ENABLED, none of which is defined anywhere. Kconfig accepts a select of an undefined symbol silently, so the reader sees a mechanism that does not exist. user_settings.h even tested CONFIG_WOLFSSL_TLS13_ENABLED alongside the real symbol; that half of the condition could never be true. Delete the file and move the two live symbols into the module's own Kconfig, next to WOLFSSL_DTLS where the other protocol options are, keeping the settings-file dependency. The dead selects go with it, as do the four dead options the two TLS samples were setting and the stale entry in .wolfssl_known_macro_extras. TLS 1.3 gains a default of y on the way across. The old file had 1.2 on and 1.3 off, which was Zephyr's mbedTLS default in 2018; wolfSSL's own configure enables both, and a module that ships TLS 1.3 off by default is not a sensible starting point now. Enabling both rather than 1.3 alone keeps interop with the TLS 1.2-only peers embedded deployments still meet, and does not quietly drop 1.2 from an existing configuration. A 1.3-only build works by clearing the 1.2 option: user_settings.h already defines WOLFSSL_NO_TLS12 when it is off. That default is also what first reached DefTicketEncCb(), since session tickets need TLS 1.3 - hence the wolfio byte-order fix earlier in this branch, without which eight of the module's own scenarios stop compiling. The ECC curve options that replaced the WOLFSSL_ECP_DP_* ones - and that do reach user_settings.h - went in earlier in this branch.
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 anywhere defined WOLFSSL_ARMASM_THUMB2, so every caller still took the ARMv8 path and the link failed on AES_*_AARCH32. It also needs WOLFSSL_ARMASM_NO_HW_CRYPTO, since Cortex-M has no AES or SHA extension and the Thumb2 code is the whole of it. The single-precision assembly had no option at all: WOLFSSL_SP_ARM_CORTEX_M_ASM sat commented out inside an #if 0 while sp_cortexm.c was already in the source list. WOLFCRYPT_INTELASM was worse: it named the 32-bit source pair while user_settings.h declared WOLFSSL_X86_64_BUILD, so aes_asm.S compiled to an empty object behind its WOLFSSL_X86_BUILD guard and aes_gcm_x86_asm.S emitted 32-bit code into a 64-bit build. It could not have produced a working image. 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: ARMv7-M and ARMv8-M mainline take Thumb2 plus the Cortex-M math, AArch64 the ARMv8 and ARM64 ones, other 32-bit ARM the ARMv8-32 and ARM32 ones, and x86_64 the Intel symmetric set with its correct 64-bit filenames. ARMv6-M and ARMv8-M baseline deliberately get no symmetric assembly. The Thumb2 port uses UBFX and LDRD, neither of which those cores have, so keying it on CONFIG_CPU_CORTEX_M would hand an M0 or M23 board code that cannot assemble. They still get the Thumb math, which is the only thing wolfCrypt ships for that profile - the same split the SP half already made. Each ARM port sets two single-precision macros, not one. WOLFSSL_SP_<cpu>_ASM compiles sp_<cpu>.c, the per-size backend for the RSA, DH and ECC sizes it covers; the unsuffixed WOLFSSL_SP_<cpu> enables the inline-asm word primitives inside sp_int.c, which is what the generic WOLFSSL_SP_MATH_ALL path uses for every other size and curve. sp_int.c's own header block names them as separate features and configure.ac sets them from separate options, neither implying the other. Defining only the _ASM half - which is what this module did - left Brainpool, custom curves and any uncovered RSA or DH size running with no assembly at all. The x86_64 set carries fe_x25519_asm.S but not the AES pair. curve25519.c takes the Intel path whenever USE_INTEL_SPEEDUP is defined, so omitting the former is a link error the moment an application enables the curve; the latter define nothing but _aesni entry points whose callers sit behind WOLFSSL_AESNI, which this module does not set, so they were bytes with no reachable caller. 32-bit x86 is not offered. Only the AES sources have an implementation at that width; sha256_asm.S, chacha_asm.S and poly1305_asm.S are all guarded to WOLFSSL_X86_64_BUILD and would contribute nothing. The x86_64 single-precision assembly is not offered either, and that one is worth recording. sp_x86_64_asm.S is AVX throughout - over fifteen hundred VEX instructions - and sp_x86_64.c calls into it unconditionally, with no CPUID dispatch and no scalar counterpart. Zephyr's x86 context switch is fxsave/fxrstor and it never sets CR4.OSXSAVE, so YMM state is neither saved nor enabled and those instructions fault. The symmetric sources are fine because they pick their implementation from CPUID at run time and now fall back correctly. Both set(TOOLCHAIN_C_FLAGS ...) calls go as well. They could never have had an effect: Zephyr applies that variable globally at zephyr/CMakeLists.txt:425 and only add_subdirectory's modules at line 788, so the assignment ran after the flags were consumed, and a plain set() in a subdirectory scope never reached the parent either. Confirmed by forcing the assignment to run unconditionally and finding neither -mcpu=cortex-a53+crypto nor -mstrict-align anywhere in the resulting compile database. HAVE___UINT128_T is defined wherever the compiler has the type. Every 64-bit single-precision backend works in 128-bit intermediates; an autoconf build learns the type is available from a configure probe, but with user settings nobody sets it and sp_int.c fails on an undeclared sp_int_word. AArch64 needs this as much as x86_64 does - qemu_cortex_a53 stops there before it ever reaches the assembler. One wolfssl_test scenario per port now covers the option in CI rather than by hand: qemu_x86_64 for Intel, qemu_cortex_a53 for AArch64, and mps2/an521/cpu0, a Cortex-M33, for Thumb2. The aarch64 one earned its keep immediately by catching an unused-constant error in the generated ML-KEM assembly, fixed earlier in this branch. Measured on frdm_rw612 with the benchmark, ops/sec: ECDSA P-256 sign 16 to 136, verify 10 to 102, RSA-2048 public 86 to 194. Thumb2 is worth 1.5x on AES-CBC and 1.3x on ChaCha20, and costs about 5% on SHA-256. wolfcrypt_test passes on frdm_rw612 and on all three QEMU targets with the option set.
wolfSSL-Fenrir-bot
requested changes
Sep 8, 2026
wolfSSL-Fenrir-bot
left a comment
wolfSSL-Fenrir-bot
left a comment
There was a problem hiding this comment.
Fenrir Automated Review — PR #11401
Scan targets checked: wolfcrypt-bugs, wolfcrypt-port-bugs, wolfcrypt-rs-bugs, wolfcrypt-src, wolfssl-bugs, wolfssl-src
Findings: 1
1 finding(s) posted as inline comments (see file-level comments below)
This review was generated automatically by Fenrir. Reported findings require changes before merge.
| * rejects a smaller one, so this is the ceiling the caller actually asked for. | ||
| * Raising it sizes the working values for a curve that is not compiled in, | ||
| * which is what an arbitrary curve passed to wc_ecc_set_custom_curve needs. */ | ||
| #if defined(WOLFSSL_SP_MATH_ALL) && SP_INT_BITS < MAX_ECC_BITS |
There was a problem hiding this comment.
Raised ECC ceiling remains clamped to 521 bits · Logic errors
MAX_ECC_BITS_USE clamps a user-raised MAX_ECC_BITS to the generic-SP default of 521 bits in ECC-only builds. Larger custom curves therefore return WC_KEY_SIZE_E despite being within the configured ceiling.
Suggested fix: For generic-SP ECC builds, derive SP_INT_BITS from MAX_ECC_BITS when the configured ECC ceiling exceeds 521.
Basis: wolfSSL configure.ac documents --with-max-ecc-bits as the number of bits supported for ECC algorithms.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Nine fixes to wolfSSL proper, then five commits reworking the Zephyr module's configuration.
None of the nine is Zephyr-specific: each is a place wolfSSL assumes a normal toolchain, a POSIX libc, or an OS that enables vector state, so any bare-metal or RTOS target hits the same wall.
Library fixes
7f595dc3362737WOLFSSL_ZEPHYRblock hands C declarations to the assembler, so no wolfSSL.Sfile built on Zephyr, on any architecture4bc2165sp_x86_64.cbinds registers with the bareasmkeyword, which strict ISO C rejectsd069f5dcpuid_set_flags()tested the AVX bits but neverOSXSAVE/XGETBV, so wolfSSL dispatched vector code on an OS that never enabled the state and the image died on#UDab9a065armv8-{aes,sha256}-asmemitaese/sha256hwith no.arch_extension crypto5ddbe55.arch_extension sha3was emitted only for Apple's assembler7197713L_mlkem_aarch64_constssat outside itsWOLFSSL_HAVE_MLKEMguard, so a-Werrorbuild with ML-KEM off cannot compile the file9232649WOLFSSL_CUSTOM_CURVESbuild fails at runtime on its own largest enabled curve withWC_KEY_SIZE_E17081fdXHTONS/XNTOHSuse the POSIXhtons/ntohs, which Zephyr declares only underCONFIG_POSIX_API9232649is off by exactly one bit: under custom curvesECC_KEY_MAX_BITS()adds a bit for orders larger than the prime, the ceiling does not, andMP_BITS_CNT()rounds that into a whole extra digit. bp256 fails at a 256-bit ceiling, bp384 at 384, bp512 at 512 - always the largest curve in the set. It also makes the overridableMAX_ECC_BITSreach the runtime guard, which it never did.Four of the nine are regenerated output. The generator changes are in https://github.com/wolfSSL/scripts/pull/675, so regeneration cannot silently drop them.
Module changes
8a62e7b,bd6b6d0- ECC curves become Kconfig options instead of a hard-coded SECP256R1. P-256 stays the default; Brainpool implies custom curves and the generic SP backend, so it is opt-in. Two Twister scenarios pin the pairings that fail at runtime rather than at build time.81b3ca4- feature Kconfigs now depend on not having a settings file. They only write the module'suser_settings.h, which such a build never reads, so they were accepted and silently ignored.d893c9a- deletesKconfig.tls-generic, Zephyr's mbedTLS file with the prefix renamed. Of its 53 symbols two reach any code, and threeselectsymbols defined nowhere. The two live ones move into the module Kconfig; TLS 1.3 gainsdefault y.95cdbe5- four assembly options collapse intoWOLFCRYPT_ASM, which derives the port from the CPU Zephyr reports. None of the four could express a working configuration. Each ARM port also needs two SP macros, not one:WOLFSSL_SP_<cpu>_ASMforsp_<cpu>.c, the unsuffixed one for thesp_int.cprimitives the generic path uses. On frdm_rw612: ECDSA P-256 sign 16 to 136 ops/sec, verify 10 to 102, RSA-2048 public 86 to 194.Verification
13 of 13 Twister configurations across
qemu_x86,qemu_x86_64,qemu_cortex_a53,mps2/an521/cpu0andnative_sim/native/64, plus 8 of 8 wolfssl-tagged scenarios in the Zephyr fork.frdm_rw612builds and links withCONFIG_WOLFCRYPT_ASM=y.There is now one scenario per assembly port, so a regression in the generated sources fails in CI rather than on hardware - the aarch64 one found
7197713on its first run.Not included
32-bit x86 (only the AES sources exist at that width); the x86_64 SP assembly (AVX throughout, called with no CPUID check and no fallback); and the AES-XTS streaming regeneration, whose C wiring is in #11386.