When the blacklist keyring was changed to allow updates from the root
user it gained an ->update() function that disallows all updates.
When the a hash is blacklisted multiple times from the builtin or
firmware-provided blacklist this spams prominent logs during boot:
[ 0.890814] blacklist: Problem blacklisting hash (-13)
This affects the firmware of various vendors. Reported have been at least:
* Samsung: https://askubuntu.com/questions/1436856/
* Acer: https://ubuntuforums.org/showthread.php?t=2478840
* MSI: https://forum.archlabslinux.com/t/blacklist-problem-blacklisting-hash-13-errors-on-boot/6674/7
* Micro-Star: https://bbs.archlinux.org/viewtopic.php?id=278860
* Lenovo: https://lore.kernel.org/lkml/[email protected]/
Changelog:
v1: https://lore.kernel.org/all/[email protected]/
v1 -> v2:
* Improve logging message to include the failed hash
* Add key_create() function without update semantics
* Use key_create() from mark_raw_hash_blacklisted() and log specific message
on -EEXIST
v2: https://lore.kernel.org/lkml/[email protected]/
v2 -> v3:
* Clarify commit titles and messages
* Drop the change to BLACKLIST_KEY_PERM from patch 3, as it was an artifact
of some obsolete version of the patch and not needed
Only the first patch has been marked for stable as otherwise the whole of
key_create() would need to be applied to stable.
Thomas Weißschuh (3):
certs: log hash value on blacklist error
KEYS: Add key_create()
certs: don't try to update blacklist keys
certs/blacklist.c | 21 ++++---
include/linux/key.h | 8 +++
security/keys/key.c | 149 +++++++++++++++++++++++++++++++++-----------
3 files changed, 132 insertions(+), 46 deletions(-)
base-commit: 84368d882b9688bfac77ce48d33b1e20a4e4a787
--
2.38.1
When the same key is blacklisted repeatedly logging at pr_err() level is
excessive as no functionality is impaired.
When these duplicates are provided by buggy firmware there is nothing
the enduser can do to fix the situation.
Instead of spamming the bootlog with errors we use a warning that can
still be seen by OEMs when testing their firmware.
Link: https://lore.kernel.org/all/[email protected]/
Link: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Thomas Weißschuh <[email protected]>
---
certs/blacklist.c | 21 ++++++++++++---------
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/certs/blacklist.c b/certs/blacklist.c
index 6e260c4b6a19..675dd7a8f07a 100644
--- a/certs/blacklist.c
+++ b/certs/blacklist.c
@@ -183,16 +183,19 @@ static int mark_raw_hash_blacklisted(const char *hash)
{
key_ref_t key;
- key = key_create_or_update(make_key_ref(blacklist_keyring, true),
- "blacklist",
- hash,
- NULL,
- 0,
- BLACKLIST_KEY_PERM,
- KEY_ALLOC_NOT_IN_QUOTA |
- KEY_ALLOC_BUILT_IN);
+ key = key_create(make_key_ref(blacklist_keyring, true),
+ "blacklist",
+ hash,
+ NULL,
+ 0,
+ BLACKLIST_KEY_PERM,
+ KEY_ALLOC_NOT_IN_QUOTA |
+ KEY_ALLOC_BUILT_IN);
if (IS_ERR(key)) {
- pr_err("Problem blacklisting hash %s: %pe\n", hash, key);
+ if (PTR_ERR(key) == -EEXIST)
+ pr_warn("Duplicate blacklisted hash %s\n", hash);
+ else
+ pr_err("Problem blacklisting hash %s: %pe\n", hash, key);
return PTR_ERR(key);
}
return 0;
--
2.38.1
Dear Thomas,
Am 18.11.22 um 05:03 schrieb Thomas Weißschuh:
> [ 0.890814] blacklist: Problem blacklisting hash (-13)
After updating the UEFI firmware of the MSI B350M-MORTAR [1] from BIOS
1.MV 06/23/2020 to BIOS 1.O6 07/13/2022 (7A37v1O6 (Beta version)), the
same (uninformative) errors were logged by Linux. With your patches, the
errors are gone.
Tested-by: Paul Menzel <[email protected]>
Kind regards,
Paul
[1]: https://de.msi.com/Motherboard/B350M-MORTAR/support