On Fri, 2025-03-21 at 15:13 +0800, lee joey wrote: > Hi Lennart, > > Lennart Poettering <mzxre...@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
