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.bottom...@hansenpartnership.com> 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/
--
Best regards,
Coiby