On Fri, 16 Jan 2026 at 17:39, Mimi Zohar [off-list ref] wrote:

On Fri, 2026-01-16 at 14:18 +0100, Ard Biesheuvel wrote:

quoted

On Fri, 16 Jan 2026 at 14:11, Mimi Zohar [off-list ref] wrote:

quoted

On Fri, 2026-01-16 at 10:41 +0100, Ard Biesheuvel wrote:

quoted

On Thu, 15 Jan 2026 at 01:43, Coiby Xu [off-list ref] wrote:

quoted

EVM and other LSMs need the ability to query the secure boot status of
the system, without directly calling the IMA arch_ima_get_secureboot
function. Refactor the secure boot status check into a general,
integrity-wide function named arch_integrity_get_secureboot.

Define a new Kconfig option CONFIG_INTEGRITY_SECURE_BOOT, which is
automatically configured by the supported architectures. The existing
IMA_SECURE_AND_OR_TRUSTED_BOOT Kconfig loads the architecture specific
IMA policy based on the refactored secure boot status code.

Reported-and-suggested-by: Mimi Zohar [off-list ref]
Suggested-by: Roberto Sassu <redacted>
Signed-off-by: Coiby Xu <redacted>
---
 arch/arm64/Kconfig                            |  1 +
 arch/powerpc/Kconfig                          |  1 +
 arch/powerpc/kernel/Makefile                  |  2 +-
 arch/powerpc/kernel/ima_arch.c                |  5 --
 arch/powerpc/kernel/integrity_sb_arch.c       | 13 +++++
 arch/s390/Kconfig                             |  1 +
 arch/s390/kernel/Makefile                     |  1 +
 arch/s390/kernel/ima_arch.c                   |  6 --
 arch/s390/kernel/integrity_sb_arch.c          |  9 +++
 arch/x86/Kconfig                              |  1 +
 arch/x86/include/asm/efi.h                    |  4 +-
 arch/x86/platform/efi/efi.c                   |  2 +-
 include/linux/ima.h                           |  7 +--
 include/linux/integrity.h                     |  8 +++
 security/integrity/Kconfig                    |  6 ++
 security/integrity/Makefile                   |  3 +
 security/integrity/efi_secureboot.c           | 56 +++++++++++++++++++
 security/integrity/ima/ima_appraise.c         |  2 +-
 security/integrity/ima/ima_efi.c              | 47 +---------------
 security/integrity/ima/ima_main.c             |  4 +-
 security/integrity/platform_certs/load_uefi.c |  2 +-
 21 files changed, 111 insertions(+), 70 deletions(-)
 create mode 100644 arch/powerpc/kernel/integrity_sb_arch.c
 create mode 100644 arch/s390/kernel/integrity_sb_arch.c
 create mode 100644 security/integrity/efi_secureboot.c

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 93173f0a09c7..4c265b7386bb 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig

@@ -2427,6 +2427,7 @@ config EFI
        select EFI_STUB
        select EFI_GENERIC_STUB
        imply IMA_SECURE_AND_OR_TRUSTED_BOOT
+       imply INTEGRITY_SECURE_BOOT

This allows both to be en/disabled individually, which I don't think
is what we want. It also results in more churn across the
arch-specific Kconfigs than needed.

Wouldn't it be better if IMA_SECURE_AND_OR_TRUSTED_BOOT 'select'ed
INTEGRITY_SECURE_BOOT in its Kconfig definition?

As much as possible, EVM (and other LSMs) shouldn't be dependent on another LSM,
in this case IMA, being configured.

Sure, but that is not my point.

This arrangement allows for IMA_SECURE_AND_OR_TRUSTED_BOOT to be
enabled without INTEGRITY_SECURE_BOOT, resulting in the stub
implementation of arch_integrity_get_secureboot() being used, which
always returns false.

I understand your concern, but instead of "select"ing INTEGRITY_SECURE_BOOT from
IMA_SECURE_AND_OR_TRUSTED_BOOT, how making IMA_SECURE_AND_OR_TRUSTED_BOOT
dependent on both IMA_ARCH_POLICY and INTEGRITY_SECURE_BOOT.

Given that INTEGRITY_SECURE_BOOT has no dependencies of its own,
afaict, selecting it is the least disruptive option, as otherwise,
existing configs will disable IMA_SECURE_AND_OR_TRUSTED_BOOT as the
kernel is being upgraded. But conceptually, I agree that they are
equivalent.

Including the "imply INTEGRITY_SECURE_BOOT" here in the arch Kconfig allows EVM
to query the secure boot state without relying on IMA_SECURE_AND_OR_TRUSTED_BOOT
being configured.

Yes, I understand that this is the whole point of the exercise. But
'imply' should be used with care, and in this case, implying both from
CONFIG_EFI really makes little sense. INTEGRITY_SECURE_BOOT should be
selected by options that need the functionality, not 'implied' by
options that might provide it.