diff options
| author | Nicolai Stange <[email protected]> | 2021-11-30 14:10:09 +0000 |
|---|---|---|
| committer | Herbert Xu <[email protected]> | 2021-12-11 05:48:06 +0000 |
| commit | 710ce4b88f9a93a6b2c2267e8f27ba65af3cb6ac (patch) | |
| tree | eb7681a897a48f8a653422d7acf37a02ba9d397b /drivers/crypto/stm32/stm32-hash.c | |
| parent | crypto: jitter - don't limit ->health_failure check to FIPS mode (diff) | |
| download | kernel-710ce4b88f9a93a6b2c2267e8f27ba65af3cb6ac.tar.gz kernel-710ce4b88f9a93a6b2c2267e8f27ba65af3cb6ac.zip | |
crypto: jitter - quit sample collection loop upon RCT failure
The jitterentropy collection loop in jent_gen_entropy() can in principle
run indefinitely without making any progress if it only receives stuck
measurements as determined by jent_stuck(). After 31 consecutive stuck
samples, the Repetition Count Test (RCT) would fail anyway and the
jitterentropy RNG instances moved into ->health_failure == 1 state.
jent_gen_entropy()'s caller, jent_read_entropy() would then check for
this ->health_failure condition and return an error if found set. It
follows that there's absolutely no point in continuing the collection loop
in jent_gen_entropy() once the RCT has failed.
Make the jitterentropy collection loop more robust by terminating it upon
jent_health_failure() so that it won't continue to run indefinitely without
making any progress.
Signed-off-by: Nicolai Stange <[email protected]>
Reviewed-by: Stephan Mueller <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Diffstat (limited to 'drivers/crypto/stm32/stm32-hash.c')
0 files changed, 0 insertions, 0 deletions
