[PATCH v3 31/34] ima,evm: move initcalls to the LSM framework
Paul Moore
paul at paul-moore.com
Mon Sep 8 01:05:41 UTC 2025
On Sun, Sep 7, 2025 at 5:13 PM Mimi Zohar <zohar at linux.ibm.com> wrote:
>
> On Fri, 2025-08-22 at 16:45 -0400, Paul Moore wrote:
> > On Thu, Aug 14, 2025 at 6:55 PM Paul Moore <paul at paul-moore.com> wrote:
> > >
> > > This patch converts IMA and EVM to use the LSM frameworks's initcall
> > > mechanism. There was a minor challenge in this conversion that wasn't
> > > seen when converting the other LSMs brought about by the resource
> > > sharing between the two related, yes independent IMA and EVM LSMs.
> > > This was resolved by registering the same initcalls for each LSM and
> > > including code in each registered initcall to ensure it only executes
> > > once during each boot.
> > >
> > > It is worth mentioning that this patch does not touch any of the
> > > "platform certs" code that lives in the security/integrity/platform_certs
> > > directory as the IMA/EVM maintainers have assured me that this code is
> > > unrelated to IMA/EVM, despite the location, and will be moved to a more
> > > relevant subsystem in the future.
>
> The "unrelated to IMA/EVM" wording misses the point. An exception was made to
> load the pre-boot keys onto the .platform keyring in order for IMA/EVM to verify
> the kexec kernel image appended signature. This exception was subsequently
> extended to verifying the pesigned kexec kernel image signature. (Other
> subsystems are abusing the keys on the .platform keyring to verify other
> signatures.)
>
> Instead of saying "unrelated to IMA/EVM", how about saying something along the
> lines of "IMA has a dependency on the platform and machine keyrings, but this
> dependency isn't limited to IMA/EVM."
>
> Paul, this patch set doesn't apply to cleanly to Linus's tree. What is the base
> commit?
It would have been based on the lsm/dev branch since the LSM tree is
the target, however, given the scope of the patchset and the fact that
it has been several weeks since it was originally posted, I wouldn't
be surprised it if needs some fuzzing when applied on top of lsm/dev
too.
--
paul-moore.com
More information about the Linux-security-module-archive
mailing list