Hi Takashi, Mimi, On Tue, Dec 14, 2021 at 04:58:47PM +0100, Takashi Iwai wrote: > On Tue, 14 Dec 2021 16:31:21 +0100, > Mimi Zohar wrote: > > > > Hi Takashi, > > > > On Mon, 2021-12-13 at 17:11 +0100, Takashi Iwai wrote: > > > Currently arch_ima_get_secureboot() and arch_get_ima_policy() are > > > defined only when CONFIG_IMA is set, and this makes the code calling > > > those functions without CONFIG_IMA failing. Although there is no such > > > in-tree users, but the out-of-tree users already hit it. > > > > > > Move the declaration and the dummy definition of those functions > > > outside ifdef-CONFIG_IMA block for fixing the undefined symbols. > > > > > > Signed-off-by: Takashi Iwai <tiwai@xxxxxxx> > > > > Before lockdown was upstreamed, we made sure that IMA and lockdown > > could co-exist. This patch makes the stub functions available even > > when IMA is not configured. Do the remaining downstream patches > > require IMA to be disabled or can IMA co-exist? > > I guess Joey (Cc'ed) can explain this better. AFAIK, currently it's > used in a part of MODSIGN stuff in SUSE kernels, and it's calling > unconditionally this function for checking whether the system is with > the Secure Boot or not. > Actually in downstream code, I used arch_ima_get_secureboot() in load_uefi_certs() to prevent the mok be loaded when secure boot is disabled. Because the security of MOK relies on secure boot. The downstream code likes this: /* the MOK and MOKx can not be trusted when secure boot is disabled */ - if (!efi_enabled(EFI_SECURE_BOOT)) + if (!arch_ima_get_secureboot()) return 0; The old EFI_SECURE_BOOT bit can only be available on x86_64, so I switch the code to to arch_ima_get_secureboot() for cross-architectures and sync with upstream api. The load_uefi.c depends on CONFIG_INTEGRITY but not CONFIG_IMA. So load_uefi.c still be built when CONFIG_INTEGRITY=y and CONFIG_IMA=n. Then "implicit declaration of function 'arch_ima_get_secureboot'" is happened. Thanks a lot! Joey Lee
