On Wed, 25 Feb 2026, at 01:03, Mimi Zohar wrote: > 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/ >
Ack. Looks fine to me.
