On Wed, 2025-06-11 at 16:27 -0400, Paul Moore wrote:

On Fri, May 30, 2025 at 6:04 PM Mimi Zohar [off-list ref] wrote:

quoted

On Wed, 2025-04-09 at 14:50 -0400, Paul Moore wrote:

quoted

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/ (local)

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.

quoted

quoted

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