Globally clear thread-local states #1919
Open
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.
Description of changes:
As per FIPS, something equivalent to sensitive memory must not be kept around in the clear. Often the sensitive stuff we produce is then handed off to a linked application. But we do have some memory we control, namely the thread-local CTR-DRBG states. It's not clear why CTR-DRBG states are actually sensitive for the purpose of zeroization; the primary security property of a DRBG is backtracking resistance, so someone would need to break the security of the scheme to take advantage of the state. Obviously, one can generate future outputs from a DRBG state, since it's deterministic. But that's not the purpose of zeroization. Regardless, zeroization is what we must do.
But when a process exists, all threads might not have been gracefully exited. To ensure this doesn't leave around sensitive memory, references to all thread-local states are kept in a doubly linked list. This creates a fair bit of issues that was mostly solved in the existing solution. I modified that a bit to take into account the new code-flow. The only major chance is that the CTR-DRBG generate call is now wrapped in a global lock under the while-loop iteration. I have tried to explain most in inline comments in the code. One can argue that when existing a process there is no need for this ands it is all just unreasonable to require, but that's the state of the world currently. And so, must be handled.
This feature was previously guarded by the FIPS build flag. But I removed that to remove one more source of non-FIPS/FIPS behaviour change...
Testing:
Extended the current basic tests to being threaded - if threading is supported by the build.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license.