If we have a config with:
CONFIG_TRUSTED_KEYS=m
CONFIG_TRUSTED_KEYS_TPM=y
CONFIG_DM_CRYPT=m
then dm-crypt.ko will depend on trusted.ko (due to using the exported
symbol 'key_type_trusted'), meaning trusted.ko will need to successfully
load before dm-crypt.ko can load.
However, since commit 9d50a25eeb05c ("crypto: testmgr - desupport SHA-1
for FIPS 140") when booting with fips=1, the SHA-1 algorithm (or anything
that uses it, like HMAC-SHA-1) will be unavailable.
security/keys/trusted-keys/trusted_tpm1.c is hard-coded to use SHA-1 and
will fail with -ENOENT when attempting to initialize the hash instance
using the crypto API _if_ the hardware is available. This in turn causes
the entire trusted.ko to fail to load.
(If TPM1 hardware is not available, trusted_tpm1.c will fail to load with
-ENODEV, which is handled in init_trusted() to allow the module to load
anyway.)
Long story short, having TPM1 hardware and booting with fips=1 will cause
dm-crypt to fail loading, even though SHA-1 may not actually be used or
needed at any point.
There's already some history of fiddling with the module init/exit code
and the return values here, but I think we can simplify the code somewhat:
- return immediately on success; there is no point in breaking out of the
loop and rechecking the return value
- return immediately on non-ENODEV/ENOENT errors; again, no point in
rechecking the return value
We could even consider retrying other trusted key sources regardless of
the exact error value, but that would change the semantics too much for
my comfort here.
Reported-by: Vijaykumar Hegde <vijaykumar.hegde@xxxxxxxxxx>
Reported-by: Sriharsha Yadagudde <sriharsha.devdas@xxxxxxxxxx>
Fixes: 9d50a25eeb05c ("crypto: testmgr - desupport SHA-1 for FIPS 140")
Cc: Sumit Garg <sumit.garg@xxxxxxxxxx>
Cc: Jarkko Sakkinen <jarkko@xxxxxxxxxx>
Cc: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Link: https://lore.kernel.org/linux-integrity/CAHk-=whOPoLaWM8S8GgoOPT7a2+nMH5h3TLKtn=R_3w4R1_Uvg@xxxxxxxxxxxxxx/
Signed-off-by: Vegard Nossum <vegard.nossum@xxxxxxxxxx>
---
security/keys/trusted-keys/trusted_core.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
index e2d9644efde1..152832735bac 100644
--- a/security/keys/trusted-keys/trusted_core.c
+++ b/security/keys/trusted-keys/trusted_core.c
@@ -370,20 +370,22 @@ static int __init init_trusted(void)
trusted_key_exit = trusted_key_sources[i].ops->exit;
migratable = trusted_key_sources[i].ops->migratable;
+ return 0;
}
- if (!ret || ret != -ENODEV)
- break;
+ /*
+ * The crypto API returns -ENOENT if it doesn't support a
+ * given hashing algorithm (e.g. SHA1 in FIPS mode).
+ */
+ if (ret != -ENODEV && ret != -ENOENT)
+ return ret;
}
/*
- * encrypted_keys.ko depends on successful load of this module even if
- * trusted key implementation is not found.
+ * encrypted_keys.ko and dm-crypt depend on successful load of
+ * this module even if trusted key implementation is not found.
*/
- if (ret == -ENODEV)
- return 0;
-
- return ret;
+ return 0;
}
static void __exit cleanup_trusted(void)
--
2.39.3
