On 7/26/2025 2:29 AM, Nayna Jain wrote: > > On 7/17/25 8:29 AM, GONG Ruiqi wrote: >> On 7/8/2025 4:35 AM, Nayna Jain wrote: >>> On 7/2/25 10:07 PM, GONG Ruiqi wrote: >>>> ... >> >> Yes, IMA_ARCH_POLICY was not set. The testing was conducted on >> openEuler[1], a Linux distro mainly for arm64 & x86, and the kernel was >> compiled based on its own openeuler_defconfig[2], which set >> IMA_ARCH_POLICY to N. > > Thanks Ruiqi for the response. > > It seems the main cause of the problem was that IMA_ARCH_POLICY config > wasn't enabled; and it sounds like you don't need IMA arch policies but > you do need the arch specific function to get the secure boot status. > > In that case, removing IMA_SECURE_AND_OR_TRUSTED_BOOT config dependency > on IMA_ARCH_POLICY config and updating the corresponding help is all > that is needed.
I think it doesn't solve the real problems, which are: 1. the implicit dependency of LOAD_UEFI_KEYS to IMA_SECURE_AND_OR_TRUSTED_BOOT, which surprises people, and 2. what arch_ima_get_secureboot() does is essentially a stand-alone function and it's not necessarily be a part of IMA, but it's still controlled by IMA_SECURE_AND_OR_TRUSTED_BOOT. I agree that adjusting Kconfig could be simpler, but breaking IMA_SECURE_AND_OR_TRUSTED_BOOT's dependency to IMA_ARCH_POLICY doesn't help on both. If that's gonna be the way we will take, what I would propose is to let LOAD_UEFI_KEYS select IMA_SECURE_AND_OR_TRUSTED_BOOT, which states the dependency explicitly so at least solves the problem 1. -Ruiqi > > The help text can be updated to: > This option is selected by architectures to detect systems with secure > and/or trusted boot enabled, in order to load the appropriate IMA > runtime policies and keys. > > Thanks & Regards, > > - Nayna >
