As suggested by Jarkko and explained by Paul, let's document the panic()
calls from the blacklist keyring initialization. This series applies on
top of commit 50c486fe3108 ("certs: Allow root user to append signed hashes to the
blacklist keyring"). This can smoothly be rebased on top of Jarkko's
next branch.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/commit/?id=50c486fe310890c134b5cb36cf9a4135475a6074
Regards,
Mickaël Salaün (1):
certs: Explain the rational to call panic()
certs/blacklist.c | 8 ++++++++
1 file changed, 8 insertions(+)
base-commit: 50c486fe310890c134b5cb36cf9a4135475a6074
--
2.35.1
From: Mickaël Salaün <[email protected]>
The blacklist_init() function calls panic() for memory allocation
errors. This change documents the reason why we don't return -ENODEV.
Suggested-by: Paul Moore <[email protected]> [1]
Requested-by: Jarkko Sakkinen <[email protected]> [1]
Link: https://lore.kernel.org/r/[email protected] [1]
Signed-off-by: Mickaël Salaün <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
---
certs/blacklist.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/certs/blacklist.c b/certs/blacklist.c
index 486ce0dd8e9c..ac26bcf9b9a5 100644
--- a/certs/blacklist.c
+++ b/certs/blacklist.c
@@ -307,6 +307,14 @@ static int restrict_link_for_blacklist(struct key *dest_keyring,
/*
* Initialise the blacklist
+ *
+ * The blacklist_init() function is registered as an initcall via
+ * device_initcall(). As a result the functionality doesn't load and the
+ * kernel continues on executing. While cleanly returning -ENODEV could be
+ * acceptable for some non-critical kernel parts, if the blacklist keyring
+ * fails to load it defeats the certificate/key based deny list for signed
+ * modules. If a critical piece of security functionality that users expect to
+ * be present fails to initialize, panic()ing is likely the right thing to do.
*/
static int __init blacklist_init(void)
{
--
2.35.1