On Fri, Mar 21, 2025 at 09:39:55AM +0100, Lennart Poettering wrote: > On Fr, 21.03.25 15:13, lee joey (joeyli.ker...@gmail.com) 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. > > 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
