Re: [PATCH RFC 1/1] module: Make use of platform keyring for module signature verify
From: Coiby Xu
Date: Sun Jun 08 2025 - 07:15:50 EST
On Thu, Jun 05, 2025 at 08:05:56AM -0400, James Bottomley wrote:
On Thu, 2025-06-05 at 16:34 +0800, Coiby Xu wrote:
On Tue, Jun 03, 2025 at 09:03:22AM -0400, James Bottomley wrote:
> On Tue, 2025-06-03 at 10:52 +0200, Vitaly Kuznetsov wrote:
> > James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> writes:
> [...]
> > > Also, are you sure a config option is the right thing?
> > > Presumably Red Hat wants to limit its number of kernels and the
> > > design of just linking the machine keyring (i.e. MoK) was for
> > > the use case where trust is being pivoted away from db by shim,
> > > so users don't want to trust the db keys they don't control.
> > > If the same kernel gets used for both situations (trusted and
> > > untrusted db) you might want a runtime means to distinguish
> > > them.
> >
> > I was not personally involved when RH put the patch downstream
> > (and wasn't very successful in getting the background story) but
> > it doesn't even have an additional Kconfig, e.g.:
> > https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/commit/03d4694fa6511132989bac0da11fa677ea5d29f6
> > so apparently there's no desire to limit anything, basically,
> > .platform is always trusted on Fedora/RHEL systems (for a long
> > time already).
>
> It sounds like that's just distro politics: RH wants to enable
> binary modules (by allowing them to be signed) but doesn't want to
> be seen to be signing them (so they can't be signed with the
> embedded RH key) so that gamers can have performant graphics
> drivers and the like. Thus it mixes in the db keyring, which
> usually contains several Microsoft certificates and also one from
> the ODM manufacturer, so now it can send would be shippers of
> binary modules to those groups to get them signed. If you only have
> the built in and MoK keyrings, the only possible signers are either
> RH or the machine owner ... who isn't a single entity to deal
> with. Personally I think this is a bit daft: Debian manages an out
> of tree module infrastructure using DKMS and MoK signing, so I
> can't see why RH can't get it to work in the same way.
It's interesting to find that although Debian's wiki page [1] only
mentions DKMS and MOK, it actually has the same downstream kernel
patch [2][3] as Fedora/RHEL to allow using db keys to verify kernel
modules.
[1] https://wiki.debian.org/SecureBoot
[2]
https://salsa.debian.org/kernel-team/linux/-/blob/debian/latest/debian/patches/features/all/db-mok-keyring/KEYS-Make-use-of-platform-keyring-for-module-signature.patch?ref_type=heads
[3]
https://sources.debian.org/patches/linux/6.12.30-1/features/all/db-mok-keyring/KEYS-Make-use-of-platform-keyring-for-module-signature.patch/
Well if you read the attached bug reports:
Thanks for listing the bug reports!
https://bugs.debian.org/935945
This bug was filed on Aug 2019 and the downstream patch was merged on
Nov 20219 whereas Eric's machine keyring work was merged on Mar 2022. So
I don't think it has anything to do with
CONFIG_INTEGRITY_MACHINE_KEYRING despite the bug reporter used MOK key
to sign an external module. And before Eric's work, all MOK keys were
loaded to the .platform keyring.
https://bugs.debian.org/1030200
For this second bug which titled ".platform keyring (EFI DB variable) no
longer trusted to sign modules, regression against 6.0", the bug
reporter was requesting to allow DB keys to verify kernel modules
(again).
You can see that it's people trying to get an external module to work
(actually zfs locally signed) by adding keys to MoK and it failed
because of a configuration error (CONFIG_INTEGRITY_MACHINE_KEYRING
wasn't set). They added this patch as part of the thrashing around
trying to fix the problem because they found it in Fedora.
So I think Debian includes the downstream patch exactly to allow using
platform keys to verify custom/third-party kernel modules.
Regards,
James
--
Best regards,
Coiby