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

[Jarkko Sakkinen <jarkko@kernel.org>]

On Fri, Mar 21, 2025 at 09:39:55AM +0100, Lennart Poettering wrote:
> On Fr, 21.03.25 15:13, lee joey (joeyli.kernel@gmail.com) 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.
> 
> Why not? as you say, chain of trust is broken: the kernel itself is
> not immediately integrity protected and neither is the firmware. Hence
> filtering out keys in this case is really pointless.

The way I look at this is that unless there is an actual threat scenario
that we protect against by hiding MOK keys, then we should not hide
those keys.

Since I don't find any threat scenarios my reviewed-by holds. Pointless
checks is security by obfuscation, which is not really security.

BR, Jarkko