On Wed, 2026-01-21 at 17:25 +0100, Ard Biesheuvel wrote: > On Wed, 21 Jan 2026 at 16:41, Mimi Zohar <[email protected]> wrote: > > > > On Mon, 2026-01-19 at 12:04 +0800, Coiby Xu wrote: > > > > > diff --git a/security/integrity/ima/Kconfig > > > b/security/integrity/ima/Kconfig > > > index 976e75f9b9ba..5dce572192d6 100644 > > > --- a/security/integrity/ima/Kconfig > > > +++ b/security/integrity/ima/Kconfig > > > @@ -311,6 +311,7 @@ config IMA_QUEUE_EARLY_BOOT_KEYS > > > config IMA_SECURE_AND_OR_TRUSTED_BOOT > > > bool > > > depends on IMA_ARCH_POLICY > > > + depends on INTEGRITY_SECURE_BOOT > > > > > > > > > Another idea is make a tree-wide arch_get_secureboot i.e. to move > > > current arch_ima_get_secureboot code to arch-specific secure boot > > > implementation. By this way, there will no need for a new Kconfig option > > > INTEGRITY_SECURE_BOOT. But I'm not sure if there is any unforeseen > > > concern. > > > > Originally basing IMA policy on the secure boot mode was an exception. As > > long > > as making it public isn't an issue any longer, this sounds to me. Ard, > > Dave, do > > you have any issues with replacing arch_ima_get_secureboot() with > > arch_get_secureboot()? > > I don't see an issue with that. If there is a legitimate need to > determine this even if IMA is not enabled, then this makes sense.
Ard, Dave - FYI, Coiby posted v3 of this patch set[1], which is queued in the next- integrity-testing branch[2]. [1] https://lore.kernel.org/linux-integrity/[email protected]/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git/ Mimi
