aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/crypto/stm32/stm32-hash.c
diff options
context:
space:
mode:
authorNicolai Stange <[email protected]>2021-11-30 14:10:08 +0000
committerHerbert Xu <[email protected]>2021-12-11 05:48:06 +0000
commitb454fb702515276041b701a4eda468b6cd6b384d (patch)
tree7344058307c647b726e1ee03a34ec79bf6e6344c /drivers/crypto/stm32/stm32-hash.c
parentcrypto: drbg - ignore jitterentropy errors if not in FIPS mode (diff)
downloadkernel-b454fb702515276041b701a4eda468b6cd6b384d.tar.gz
kernel-b454fb702515276041b701a4eda468b6cd6b384d.zip
crypto: jitter - don't limit ->health_failure check to FIPS mode
The jitterentropy's Repetition Count Test (RCT) as well as the Adaptive Proportion Test (APT) are run unconditionally on any collected samples. However, their result, i.e. ->health_failure, will only get checked if fips_enabled is set, c.f. the jent_health_failure() wrapper. I would argue that a RCT or APT failure indicates that something's seriously off and that this should always be reported as an error, independently of whether FIPS mode is enabled or not: it should be up to callers whether or not and how to handle jitterentropy failures. Make jent_health_failure() to unconditionally return ->health_failure, independent of whether fips_enabled is set. Note that fips_enabled isn't accessed from the jitterentropy code anymore now. Remove the linux/fips.h include as well as the jent_fips_enabled() wrapper. 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