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

James Bottomley
2025-03-21T13:19:06Z

On Fri, 2025-03-21 at 15:13 +0800, lee joey wrote:
> Hi Lennart,
>
> Lennart Poettering <mzxreary@0pointer.de> 於 2025年3月20日 週四 下午8:02寫道：
> >
> > 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.
> >
>
> SB off means that the chain of trust is broken. Which means that all
> mechanisms rely on SB are non-secure. Meanwhile, if the integrity of
> kernel can be guaranteed by other mechanism (e.g. TPM), then mok
> should not be loaded when SB off.

I think the point being made here is that there are other integrity
mechanisms than secure boot which can protect the early boot
environment.

A second argument would be that we still load the UEFI certificates
into the chain, and they have exactly the same early boot guarantees as
the MOK ones, so we're not being consistent: we should load all of them
all the time or none. The boot envelope still has some protections
even without secure boot or anything else.

The third must be the module one: we've trained users to insert module
signing certificates into MOK. If they find that mechanism doesn't
work under some possible circumstances they're going to be unhappy.

Part of the problem with that last is with the lockdown creep we're
increasing the chances that users will see turning off secure boot as
the solution to fixing some lockdown problems (say they want hibernate
for instance) so having the kernel be unable to load external modules
in that case when they're trying to relax protections is highly counter
intuitive.

Regards,

James