Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Globally clear thread-local states #1919

Conversation

torben-hansen
Copy link
Contributor

@torben-hansen torben-hansen commented Oct 15, 2024

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.

@codecov-commenter
Copy link

codecov-commenter commented Oct 15, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 78.78%. Comparing base (72f0a9f) to head (e826b71).
Report is 1 commits behind head on randomness_generation.

Additional details and impacted files
@@                    Coverage Diff                    @@
##           randomness_generation    #1919      +/-   ##
=========================================================
+ Coverage                  78.57%   78.78%   +0.21%     
=========================================================
  Files                        585      595      +10     
  Lines                      98007   101780    +3773     
  Branches                   13922    14425     +503     
=========================================================
+ Hits                       77010    80192    +3182     
- Misses                     20378    20950     +572     
- Partials                     619      638      +19     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@torben-hansen torben-hansen marked this pull request as ready for review October 15, 2024 18:05
@torben-hansen torben-hansen requested a review from a team as a code owner October 15, 2024 18:05
torben-hansen added a commit that referenced this pull request Nov 1, 2024
To avoid synchronisation issues for codepoints that reads/mutates the ctr-drbg state in #1919, we must reorganise the reseed logic. This decouples the code that reads/mutates the ctr-drbg state and the code that gathers entropy. The latter is not an issue. The former will later be wrapped as critical code needing synchronisation as part of the global zeroisation.
torben-hansen added a commit to torben-hansen/aws-lc that referenced this pull request Nov 1, 2024
To avoid synchronisation issues for codepoints that reads/mutates the ctr-drbg state in aws#1919, we must reorganise the reseed logic. This decouples the code that reads/mutates the ctr-drbg state and the code that gathers entropy. The latter is not an issue. The former will later be wrapped as critical code needing synchronisation as part of the global zeroisation.
crypto/fipsmodule/rand/new_rand.c Show resolved Hide resolved
crypto/fipsmodule/rand/new_rand.c Outdated Show resolved Hide resolved
crypto/fipsmodule/rand/new_rand.c Outdated Show resolved Hide resolved
crypto/fipsmodule/rand/new_rand.c Outdated Show resolved Hide resolved
crypto/fipsmodule/rand/new_rand.c Show resolved Hide resolved
crypto/fipsmodule/rand/new_rand_test.cc Show resolved Hide resolved
skmcgrail
skmcgrail previously approved these changes Nov 5, 2024
andrewhop
andrewhop previously approved these changes Nov 6, 2024
@torben-hansen torben-hansen merged commit 3b6651c into aws:randomness_generation Nov 7, 2024
112 of 116 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants