Re: [PATCH RFC 0/1] module: Optionally use .platform keyring for signatures verification

James Bottomley [off-list ref] writes:

On Thu, 2025-06-05 at 09:54 +0200, Vitaly Kuznetsov wrote:

quoted

One additional consideration is the fact that we already trust 'db'
for dm-verity (since 6fce1f40e951) and kexec (since 278311e417be) and
especially the later gives someone who is able to control 'db' access
to CPL0; a 'db'-signed module (IMO) wouldn't change much.

Well, the kexec case is because kexec has to verify the new kernel as
shim would and shim would use the UEFI keys.  The dm-verity one was
added for a cloud use case by pressuring the maintainers in spite of
the objection to using the platform keyring (it went to dm-devel only
so not many integrity people saw it):

https://lore.kernel.org/all/20240617220037.594792-1-luca.boccassi@gmail.com/ (local)

The point here is I do think the cloud use case is legitimate, but it
can't be supported simply by ignoring the bare metal security domain
separation concerns of the integrity community.  The argument that
distros have done it so it must be safe isn't really a winning one
(especially as there's no clear explanation of why they did it).  So
either you need a better argument or we need a way to support both sets
of communities ... which is why I was wondering about a runtime
differentiator.

So far, I got two 'runtime' ideas:
- Observe MokListTrustedRT and distrust .platform when it is
non-empty. This can, of course, be combine with a Kconfig for those, who
do not want it at all.

and/or
- Sysctl toggle. Keep things as they are by default but make .platform
trusted (either for modules or for everything) when switched 'on'. This
can (optionally) by combined with a previous idea and have e.g. an
'auto' state for the toggle which follows MokListTrustedRT.

-- 
Vitaly