[PATCH] Revert "integrity: Do not load MOK and MOKx when secure boot be disabled"

[Lennart Poettering]

On Fr, 04.07.25 09:30, GONG Ruiqi (gongruiqi1 at huawei.com) wrote:

> > patch arbitrary keys into the ELF image of the kernel before starting
> > it, and everything will look perfect later on, because the image is
> > not authenticated after all via SB. So there *already* is a way into
> > the kernel keyring with this – it's just really messy to parse and
> > patch ELF at runtime like this from the bootloader. My hope with just
> > relaxing the rules on MOK keys when SB is off is to just make this
> > stuff cleaner and more elegant (and also to leave the ELF image intact
> > so that we get clean measurements, both of the kernel and of the keys
> > we add).
>
> Just curious: if an attacker takes control of the boot phase earlier
> than the kernel, then not just this check has no value, but any check in
> the kernel has no value, right? Anything that got loaded early enough
> could theoretically patch the kernel with anything on anywhere. So shall
> we just remove them all?

Measured boot protects you against that, as I explained: what we do in
our model is lock the full disk encryption to a key in the TPM that
enforces an local attestation policy: only if a all measurements match
that policy the FDE key is released to the OS. Hence yes, if SB is off
*any* code can run, but if it's not the right code then it cannot
unlock the disk. If it *is* able to unlock the FDE however, then this
is proof that the boot chain is in order, and hence the kernel can be
trusted, and it makes sense for it to defend itself from later steps.

> Certainly the answer is no, and they are still meaningful somehow and
> somewhere. IMHO I think the concern behind the check is reasonable, but
> the actual code could be an overkill. It would be better if it does:
>
>   if (arch_ima_get_secureboot() && ima_mok_verify()) // hypothetical
>
> , and in the future we could extend the ima policy for the boot phase
> chain of trust and perform the check here accordingly, i.e. let the
> users decide how things should go.
>
> While for the current situation, my personal advice would be to add a
> config to control whether or not the check is conducted. Let's call it
> CONFIG_LOAD_UEFI_KEYS_STRICT temporarily:
>
> #ifdef CONFIG_LOAD_UEFI_KEYS_STRICT
>   /* the MOK/MOKx can not be trusted when secure boot is disabled */
>   if (!arch_ima_get_secureboot())
>           return 0;
> #endif
>
> so that both sides are happy, and we can think of more fine-grained
> verification methods, like the one I said above, for the strict mode
> afterwards.

Having an option for this would be better than nothing of course, but
I seriously wonder what the value of the check is supposed to be at
all. SecureBoot=off tells the system: hey, please accept any boot-time
resource without validation, and firmware and boot loaders honour that,
but Linux then does the opposite, invents some artificial checks not
even done if SB is on!

I mean, a boot trust chain means: trust what comes before, and
authenticate/measure what comes next before you pass control to it.

But for some reason Linux makes up a different model, where if told to
not authenticate it suddenly doesn't trust half of what comes before
anymore, but the other half it does. And that's just bogus, and
illogical.

Lennart

--
Lennart Poettering, Berlin