James Bottomley <james.bottom...@hansenpartnership.com> writes: > On Thu, 2025-06-05 at 09:54 +0200, Vitaly Kuznetsov wrote: >> 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.bocca...@gmail.com/ > > 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
