20260512-wc_init_state#10472
Conversation
wolfSSL-Fenrir-bot
left a comment
There was a problem hiding this comment.
Fenrir Automated Review — PR #10472
Scan targets checked: wolfcrypt-bugs, wolfcrypt-src
No new issues found in the changed files. ✅
17b7825 to
74aea5b
Compare
|
|
retest this please |
julek-wolfssl
left a comment
There was a problem hiding this comment.
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.
|
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. |
* wc_local_InitUp() * wc_local_InitUpDone() * wc_local_InitDown() * wc_local_InitDownDone() * wc_init_state_t * WC_DECLARE_INIT_STATE() * WC_INIT_STATE_* * union wc_init_state_bitfields * WC_INIT_STATE_RAISE_BAD_STATE(); fix&refactor thread safety mechanisms in wolfCrypt_Init() and wolfCrypt_Cleanup(), and fix a few preexisting error-handling flubs in wolfCrypt_Init().
74aea5b to
df7d3da
Compare
wolfSSL-Fenrir-bot
left a comment
There was a problem hiding this comment.
Fenrir Automated Review — PR #10472
Scan targets checked: wolfcrypt-bugs, wolfcrypt-src
No new issues found in the changed files. ✅
wolfcrypt/src/wc_port.c: fix&refactor thread safety mechanisms inwolfCrypt_Init()andwolfCrypt_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