On Fri, Oct 10, 2025 at 12:54 PM Mimi Zohar <[email protected]> wrote: > On Tue, 2025-09-30 at 16:11 -0400, Paul Moore wrote: > > On Tue, Sep 16, 2025 at 6:14 PM Paul Moore <[email protected]> wrote: > > > > > > From: Roberto Sassu <[email protected]> > > > > > > This patch converts IMA and EVM to use the LSM frameworks's initcall > > > mechanism. It moved the integrity_fs_init() call to ima_fs_init() and > > > evm_init_secfs(), to work around the fact that there is no "integrity" > > > LSM, > > > and introduced integrity_fs_fini() to remove the integrity directory, if > > > empty. Both integrity_fs_init() and integrity_fs_fini() support the > > > scenario of being called by both the IMA and EVM LSMs. > > > > > > This patch does not touch any of the platform certificate code that > > > lives under the security/integrity/platform_certs directory as the > > > IMA/EVM developers would prefer to address that in a future patchset. > > > > > > Signed-off-by: Roberto Sassu <[email protected]> > > > [PM: adjust description as discussed over email] > > > Signed-off-by: Paul Moore <[email protected]> > > > --- > > > security/integrity/evm/evm_main.c | 3 +-- > > > security/integrity/evm/evm_secfs.c | 11 +++++++++-- > > > security/integrity/iint.c | 14 ++++++++++++-- > > > security/integrity/ima/ima_fs.c | 11 +++++++++-- > > > security/integrity/ima/ima_main.c | 4 ++-- > > > security/integrity/integrity.h | 2 ++ > > > 6 files changed, 35 insertions(+), 10 deletions(-) > > > > I appreciate you reviewing most (all?) of the other patches in this > > patchset, but any chance you could review the IMA/EVM from Roberto? > > This is the only patch that really needs your review ... > > Paul, I'm sorry for the long delay in reviewing and testing this patch set. > It > wasn't enough to just review this one patch, but it needed to be reviewed in > context. > > The initcall ordering is extremely important for IMA. IMA-measurement needs to > be initialized after the TPM, otherwise IMA goes into TPM-bypass mode. As > expected, the initcall ordering seems to be fine. However this patch set > modifies the initcall debugging. > > The kernel boot command line option "initcall_debug" outputs "entering > initcall > level:" messages for each of the initcall levels, and "calling ...." and > "initcall ..." messages for the individual initcalls. > > For example, > [ 0.896556] entering initcall level: arch > [ 0.896556] calling report_snp_info+0x0/0xd0 @ 1 > [ 0.896556] initcall report_snp_info+0x0/0xd0 returned 0 after 0 usecs > > With this patch set, the "calling ..." and "initcall ..." messages will not be > emitted for the LSMs. In lieu of these messages, the patch set defines a new > boot command line option "lsm.debug" ...
This is not a new kernel command line option, oddly enough Kees wrote the patch exactly seven years ago today and we first saw it released in Linux v4.20. > which outputs "LSM: entering .... > initcall". > > For example, > [ 2.225821] calling security_initcall_late+0x0/0xc0 @ 1 > [ 2.225825] LSM: running ima late initcall > > Regardless as to whether the performance information is actually necessary, > the > initcall debugging change should probably be documented. Maybe update > initcall_debug to reference lsm.debug in Documentation/admin-guide/kernel- > parameters.txt. Thank you for the input, but I would just prefer to leave it as-is. -- paul-moore.com
