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.
