summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorNicolai Stange <nstange@suse.de>2021-11-30 15:10:09 +0100
committerHerbert Xu <herbert@gondor.apana.org.au>2021-12-11 06:48:06 +0100
commit710ce4b88f9a93a6b2c2267e8f27ba65af3cb6ac (patch)
treeeb7681a897a48f8a653422d7acf37a02ba9d397b
parentcrypto: jitter - don't limit ->health_failure check to FIPS mode (diff)
downloadlinux-710ce4b88f9a93a6b2c2267e8f27ba65af3cb6ac.tar.xz
linux-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 <nstange@suse.de> Reviewed-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-rw-r--r--crypto/jitterentropy.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/crypto/jitterentropy.c b/crypto/jitterentropy.c
index 24e087c3f526..8f5283f28ed3 100644
--- a/crypto/jitterentropy.c
+++ b/crypto/jitterentropy.c
@@ -547,7 +547,7 @@ static void jent_gen_entropy(struct rand_data *ec)
/* priming of the ->prev_time value */
jent_measure_jitter(ec);
- while (1) {
+ while (!jent_health_failure(ec)) {
/* If a stuck measurement is received, repeat measurement */
if (jent_measure_jitter(ec))
continue;