[RFC PATCH 25/29] ima,evm: move initcalls to the LSM framework

[Mimi Zohar]

On Wed, 2025-06-11 at 16:27 -0400, Paul Moore wrote:
> On Fri, May 30, 2025 at 6:04 PM Mimi Zohar <zohar at linux.ibm.com> wrote:
> > On Wed, 2025-04-09 at 14:50 -0400, Paul Moore wrote:
> > > This patch converts IMA and EVM to use the LSM frameworks's initcall
> > > mechanism.  There were two challenges to doing this conversion: the
> > > first simply being the number of initcalls across IMA and EVM, and the
> > > second was the number of resources shared between the two related,
> > > yet independent LSMs.
> > 
> > There are a number of the initcalls under integrity/platform/, which load arch
> > specific keys onto the platform and machine keyrings, which shouldn't be
> > included in this patch.
> 
> I don't want to assume too much from your reply, but if the cert/key
> loading under integrity/platform shouldn't be subject to the LSM
> initcall rework, that implies that the integrity/platform cert/key
> loading is independent of IMA/EVM and should perhaps live somewhere
> else, e.g. security/keys?
> 
> Or am I misunderstanding something?

When the .platform keyring was upstreamed it was upstreamed for a very specific
purpose so that IMA could verify the kexec kernel image.  Afterwareds it was
immediately used to verify the pesigned kexec image.  Now it is being (ab)used
by other subsystems - ipe and dm-verity - and is being proposed by the "[PATCH
RFC 0/1] module: Optionally use .platform keyring for signatures verification".
>From an integrity perspective this is definitely not a good idea.  The
discussion, which I'm sure you're aware of, is here:
https://lore.kernel.org/linux-integrity/20250602132535.897944-1-vkuznets@redhat.com/

It does not make any sense to move the code for the platform and machine
keyrings to security/keys.  If they need to move anywhere, it would be to the
certs/ directory.

> 
> > > The first problem was resolved by the creation of two new functions,
> > > integrity_device_init() and integrity_late_init(), with each focused on
> > > calling all of the various IMA/EVM initcalls for a single initcall type.
> > > The second problem was resolved by registering both of these new
> > > functions as initcalls for each LSM and including code in each
> > > registered initcall to ensure it only executes once.
> > 
> > With the above change, there obviously will be a lot fewer initcalls, but it
> > might still make sense to keep the common ima/evm function.
> 
> I'm not sure I understand, what do you mean by "common ima/evm
> function"?  This patch doesn't remove any IMA/EVM functions, it adds
> the integrity_device_init() and integrity_late_init() functions to
> setup and populate some keyrings.

"The above change" refers to not including the platform and the arch specific
calls or machine keyring initcalls.  By not including them, there are a lot
fewer initcalls in this ima,evm patch.

Mimi