From: Lennart Poettering <mzxreary@0pointer.de>
To: Jarkko Sakkinen <jarkko@kernel.org>,
Mimi Zohar <zohar@linux.ibm.com>,
Roberto Sassu <roberto.sassu@huawei.com>,
Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
Eric Snowberg <eric.snowberg@oracle.com>,
Paul Moore <paul@paul-moore.com>,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
linux-integrity@vger.kernel.org, keyrings@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, "Lee,
Chun-Yi" <joeyli.kernel@gmail.com>
Subject: [PATCH] Revert "integrity: Do not load MOK and MOKx when secure boot be disabled"
Date: Thu, 20 Mar 2025 13:02:13 +0100 [thread overview]
Message-ID: <Z9wDxeRQPhTi1EIS@gardel-login> (raw)
This reverts commit 92ad19559ea9a8ec6f158480934ae26ebfe2c14f.
This original commit this reverts creates a strange situation: it
ensures more restrictive behaviour if SecureBoot is off then when it
is on, which is the opposite of what one would expect.
Typically, one would expect that if SB is off the validation of
resources during the pre-kernel and kernel initialization is less
restrictive, not more restrictive. But this check turned the world on
its head.
I'd like to ask for this commit to be reverted. If SB is on all bets are
off regarding integrity of boot loaders and stuff, hence it makes no
sense to be restrictive here: you cannot regain integrity once you gave
it up once, hence if all bets are off anyway we might as well import any
Mok keys passed to us into the kernel keyring.
Or to say this differently: if an attacker got control of the pre-kernel
boot phase they might as well patch around in the firmware apis to make
the kernel believe it is in SB mode even if it is not. Hence the check
carries no value. It doesn't protect anything in any effective way.
The reason i'd like this check to go is that I'd like a nice way to
insert keys from pre-boot into into the kernel keyring for use with
signed dm-verity, without requiring recompilation of the kernel, and
without SB database games. i.e. i'd like to use a regular, signed
distro kernel, and pass to it additional keys to insert into the
kernel keyring in a reasonable way. The mok stuff would be great for that,
except it all falls apart once SB is off.
You might wonder what signed dm-verity gives me if I have SB off. If
we authenticate the boot phase up to Linux userspace via TPM-based PCR
policies (i.e. measured boot) we can be sure of the boot integrity
without having to rely on SB. But then we'd still like to use
dm-verity based code signing for userspace.
---
security/integrity/platform_certs/load_uefi.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/security/integrity/platform_certs/load_uefi.c b/security/integrity/platform_certs/load_uefi.c
index d1fdd113450a..7783bcacd26c 100644
--- a/security/integrity/platform_certs/load_uefi.c
+++ b/security/integrity/platform_certs/load_uefi.c
@@ -7,7 +7,6 @@
#include <linux/err.h>
#include <linux/efi.h>
#include <linux/slab.h>
-#include <linux/ima.h>
#include <keys/asymmetric-type.h>
#include <keys/system_keyring.h>
#include "../integrity.h"
@@ -211,10 +210,6 @@ static int __init load_uefi_certs(void)
kfree(dbx);
}
- /* the MOK/MOKx can not be trusted when secure boot is disabled */
- if (!arch_ima_get_secureboot())
- return 0;
-
mokx = get_cert_list(L"MokListXRT", &mok_var, &mokxsize, &status);
if (!mokx) {
if (status == EFI_NOT_FOUND)
--
2.48.1
Lennart
--
Lennart Poettering, Berlin
next reply other threads:[~2025-03-20 12:12 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-20 12:02 Lennart Poettering [this message]
2025-03-20 14:52 ` [PATCH] Revert "integrity: Do not load MOK and MOKx when secure boot be disabled" Jarkko Sakkinen
2025-03-21 7:13 ` lee joey
2025-03-21 8:39 ` Lennart Poettering
2025-03-22 21:24 ` Jarkko Sakkinen
2025-03-21 13:19 ` James Bottomley
2025-07-03 1:40 ` Mimi Zohar
2025-07-03 7:18 ` Lennart Poettering
2025-07-03 11:23 ` Mimi Zohar
2025-07-03 13:04 ` Lennart Poettering
2025-07-03 23:56 ` Mimi Zohar
2025-07-04 7:34 ` Lennart Poettering
2025-07-08 20:52 ` Mimi Zohar
2025-07-04 1:30 ` GONG Ruiqi
2025-07-04 7:47 ` Lennart Poettering
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z9wDxeRQPhTi1EIS@gardel-login \
--to=mzxreary@0pointer.de \
--cc=dmitry.kasatkin@gmail.com \
--cc=eric.snowberg@oracle.com \
--cc=jarkko@kernel.org \
--cc=jmorris@namei.org \
--cc=joeyli.kernel@gmail.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=roberto.sassu@huawei.com \
--cc=serge@hallyn.com \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).