20260512-wc_init_state

[douzzer]

wolfcrypt/src/wc_port.c: fix&refactor thread safety mechanisms in wolfCrypt_Init() and wolfCrypt_Cleanup().

This PR fixes unmitigated races in the incumbent code whereby three or more threads racing each other are subject to UB, with one or more of the threads returning success with the library not actually initialized.

The new algorithm is airtight, always succeeding unless API abuse or memory corruption.

tested with

wolfssl-multi-test.sh ...
check-source-text all-gcc-c99 all-c89-clang-tidy clang-tidy-all-intelasm clang-tidy-all-async-quic single-threaded clang-tidy-all-sp-all

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #10472

Scan targets checked: wolfcrypt-bugs, wolfcrypt-src

No new issues found in the changed files. ✅

[github-actions]

MemBrowse Memory Report

gcc-arm-cortex-m4

• FLASH: .text +128 B (+0.1%, 198,145 B / 262,144 B, total: 76% used)

gcc-arm-cortex-m4-baremetal

• FLASH: .text +192 B (+0.3%, 65,019 B / 262,144 B, total: 25% used)

gcc-arm-cortex-m4-tls12

• FLASH: .text +128 B (+0.1%, 121,565 B / 262,144 B, total: 46% used)
  No memory changes detected for:
• gcc-arm-cortex-m4-min-ecc

[douzzer]

retest this please

[julek-wolfssl]

This solution is quite complex. Can't we use the same approach of two vars (atomic + volatile) from wolfSSL_Init? The main improvement I can see in the relation between wolfSSL_Init and wolfSSL_Cleanup is that wolfSSL_Cleanup should not do anything if inits_count_mutex_valid is not 1.

[douzzer]

This solution uses a single 32 bit atomic. That's the simplest implementation supported by the hardware.

We're only doing this because code review uncovered races in the previous implementation.

And the refactored implementation only looks complex because I added a bunch of error-checking.