UEFI SecureBoot 'db' keys are currently not trusted for modules signatures
verification. RedHat based downstream distros (RHEL, Fedora, ...) carry a
patch changing that for many years (since 2019 at least). This RFC is an
attempt to upstream it as the functionality seems to be generally useful.

Previously, pre-boot keys (SecureBoot 'db', MOK) were not trusted within
kernel at all. Things have changed since '.machine' keyring got introduced
making MOK keys optionally trusted. Before that, there was a discussion to
make .platform trusted by default:
https://lore.kernel.org/lkml/1556116431-7129-1-git-send-email-robeholmes@gmail.com/
which didn't go very far because the assumption was that this is only useful
when the user has control over 'db'. I believe there's a fairly common
use-case where this is true.

The use-case: virtualized and cloud infrastructure generally provide an
ability to customize SecureBoot variables, in particular, it is possible
to bring your own SecureBoot 'db'. This may come handy when a user wants to
load a third party kernel module (self built or provided by a third party
vendor) while still using a distro provided kernel. Generally, distro
provided kernels sign modules with an ephemeral key and discard the private
part during the build. While MOK can sometimes be used to sign something
out-of-tree, it is a tedious process requiring either a manual intervention
with shim or a 'certmule' 
(see https://blogs.oracle.com/linux/post/the-machine-keyring). In contrast,
the beauty of using SecureBoot 'db' in this scenario is that for public
clouds and virtualized infrastructure it is normally a property of the OS
image (or the whole infrastructure/host) and not an individual instance;
this means that all instances created from the same template will have 'db'
keys in '.platform' by default.

The suggested approach is not to change the default, but to introduce a
Kconfig variable (CONFIG_MODULE_SIG_PLATFORM) doing the job. Note, the 
kernel already trusts '.platform' for kexec (see commit 278311e417be 
("kexec, KEYS: Make use of platform keyring for signature verify"))
and dm-verity (see commit 6fce1f40e951 ("dm verity: add support for
signature verification with platform keyring")) so maybe changing the
default or introducing a generic '.plarform is fully trusted' option
would actually be better.

Vitaly Kuznetsov (1):
  module: Make use of platform keyring for module signature verify

 Documentation/admin-guide/module-signing.rst |  6 ++++++
 kernel/module/Kconfig                        | 11 +++++++++++
 kernel/module/signing.c                      |  9 ++++++++-
 security/integrity/Kconfig                   |  2 +-
 4 files changed, 26 insertions(+), 2 deletions(-)

-- 
2.49.0

On Mon, 2025-06-02 at 15:25 +0200, Vitaly Kuznetsov wrote:
> UEFI SecureBoot 'db' keys are currently not trusted for modules signatures
> verification. RedHat based downstream distros (RHEL, Fedora, ...) carry a
> patch changing that for many years (since 2019 at least). This RFC is an
> attempt to upstream it as the functionality seems to be generally useful.
> 
> Previously, pre-boot keys (SecureBoot 'db', MOK) were not trusted within
> kernel at all. Things have changed since '.machine' keyring got introduced
> making MOK keys optionally trusted.

The changes were made incrementally:

The original trust model relied on the secure boot signature chain of trust.
After pivoting root, only keys that were built into the kernel were trusted. 
Anyone building a kernel could embed their keys in the kernel image, but there
was no way of loading other keys.

- The original exception was for verifying the kexec kernel image.  For that
reason and that reason alone, the pre-boot keys were loaded onto the platform
keyring.

- From an IMA perspective, the second exception allowed loading public keys
needed for verifying locally signed code.  The first attempt stored and loaded
keys from the TPM.  (Unfortunately) instead, what was upstreamed was loading
public keys stored in MOK.  There's an option to only load CA certificates
stored in MOK, which would be "safer".

Changing the existing behavior will impact everyone's security/integrity
assumptions of the existing system trusted keyrings. 

What's clear today is that we need finer key granularity than at the level of
keyrings.

Mimi

> Before that, there was a discussion to
> make .platform trusted by default:
> https://lore.kernel.org/lkml/1556116431-7129-1-git-send-email-robeholmes@gmail.com/
> which didn't go very far because the assumption was that this is only useful
> when the user has control over 'db'. I believe there's a fairly common
> use-case where this is true.
> 
> The use-case: virtualized and cloud infrastructure generally provide an
> ability to customize SecureBoot variables, in particular, it is possible
> to bring your own SecureBoot 'db'. This may come handy when a user wants to
> load a third party kernel module (self built or provided by a third party
> vendor) while still using a distro provided kernel. Generally, distro
> provided kernels sign modules with an ephemeral key and discard the private
> part during the build. While MOK can sometimes be used to sign something
> out-of-tree, it is a tedious process requiring either a manual intervention
> with shim or a 'certmule' 
> (see https://blogs.oracle.com/linux/post/the-machine-keyring). In contrast,
> the beauty of using SecureBoot 'db' in this scenario is that for public
> clouds and virtualized infrastructure it is normally a property of the OS
> image (or the whole infrastructure/host) and not an individual instance;
> this means that all instances created from the same template will have 'db'
> keys in '.platform' by default.
> 
> The suggested approach is not to change the default, but to introduce a
> Kconfig variable (CONFIG_MODULE_SIG_PLATFORM) doing the job. Note, the 
> kernel already trusts '.platform' for kexec (see commit 278311e417be 
> ("kexec, KEYS: Make use of platform keyring for signature verify"))
> and dm-verity (see commit 6fce1f40e951 ("dm verity: add support for
> signature verification with platform keyring")) so maybe changing the
> default or introducing a generic '.plarform is fully trusted' option
> would actually be better.
> 
> Vitaly Kuznetsov (1):
>   module: Make use of platform keyring for module signature verify
> 
>  Documentation/admin-guide/module-signing.rst |  6 ++++++
>  kernel/module/Kconfig                        | 11 +++++++++++
>  kernel/module/signing.c                      |  9 ++++++++-
>  security/integrity/Kconfig                   |  2 +-
>  4 files changed, 26 insertions(+), 2 deletions(-)
> 

> On Jun 2, 2025, at 7:25 AM, Vitaly Kuznetsov <vkuznets@redhat.com> wrote:
> 
> UEFI SecureBoot 'db' keys are currently not trusted for modules signatures
> verification. RedHat based downstream distros (RHEL, Fedora, ...) carry a
> patch changing that for many years (since 2019 at least). This RFC is an
> attempt to upstream it as the functionality seems to be generally useful.
> 
> Previously, pre-boot keys (SecureBoot 'db', MOK) were not trusted within
> kernel at all. Things have changed since '.machine' keyring got introduced
> making MOK keys optionally trusted. Before that, there was a discussion to
> make .platform trusted by default:
> https://lore.kernel.org/lkml/1556116431-7129-1-git-send-email-robeholmes@gmail.com/
> which didn't go very far because the assumption was that this is only useful
> when the user has control over 'db'. I believe there's a fairly common
> use-case where this is true.
> 
> The use-case: virtualized and cloud infrastructure generally provide an
> ability to customize SecureBoot variables, in particular, it is possible
> to bring your own SecureBoot 'db'. This may come handy when a user wants to
> load a third party kernel module (self built or provided by a third party
> vendor) while still using a distro provided kernel. Generally, distro
> provided kernels sign modules with an ephemeral key and discard the private
> part during the build. While MOK can sometimes be used to sign something
> out-of-tree, it is a tedious process requiring either a manual intervention
> with shim or a 'certmule' 
> (see https://blogs.oracle.com/linux/post/the-machine-keyring). In contrast,
> the beauty of using SecureBoot 'db' in this scenario is that for public
> clouds and virtualized infrastructure it is normally a property of the OS
> image (or the whole infrastructure/host) and not an individual instance;
> this means that all instances created from the same template will have 'db'
> keys in '.platform' by default.

Hasn’t this approach been rejected multiple times in the past?

The addition of the certmule (now called certwrapper) was precisely added 
for the use case you’ve described. If they control the ‘db’, they can create a 
certwrapper containing their key.

With the machine keyring, the end-user is in control. If they don’t want to 
trust MOK keys in their kernel, they have the ability to disable it. This will 
prevent shim from creating the MokListTrustedRT var and prevent Linux 
from using MOK keys to validate kernel modules.

On Wed, 2025-06-04 at 17:01 +0000, Eric Snowberg wrote:
> > On Jun 2, 2025, at 7:25 AM, Vitaly Kuznetsov <vkuznets@redhat.com> 
> > The use-case: virtualized and cloud infrastructure generally
> > provide an ability to customize SecureBoot variables, in
> > particular, it is possible to bring your own SecureBoot 'db'. This
> > may come handy when a user wants to load a third party kernel
> > module (self built or provided by a third party vendor) while still
> > using a distro provided kernel. Generally, distro provided kernels
> > sign modules with an ephemeral key and discard the private part
> > during the build. While MOK can sometimes be used to sign something
> > out-of-tree, it is a tedious process requiring either a manual
> > intervention with shim or a 'certmule' (see
> > https://blogs.oracle.com/linux/post/the-machine-keyring). In
> > contrast, the beauty of using SecureBoot 'db' in this scenario is
> > that for public clouds and virtualized infrastructure it is
> > normally a property of the OS image (or the whole
> > infrastructure/host) and not an individual instance; this means
> > that all instances created from the same template will have 'db'
> > keys in '.platform' by default.
> 
> Hasn’t this approach been rejected multiple times in the past?

Well not rejected, just we always thought that people (like me) who
take control of their secure boot systems are a tiny minority who can
cope with being different.  I have to say the embedding of all the
variable manipulations in shim made it quite hard.  However you can use
the efitools KeyTool to get a graphical method for adding MoK keys even
in the absence of shim.

The question is, is there a growing use case for db users beyond the
exceptions who own their own keys on their laptop, in which case we
should reconsider this.

Regards,

James

James Bottomley <James.Bottomley@HansenPartnership.com> writes:

> On Wed, 2025-06-04 at 17:01 +0000, Eric Snowberg wrote:
>> > On Jun 2, 2025, at 7:25 AM, Vitaly Kuznetsov <vkuznets@redhat.com> 
>> > The use-case: virtualized and cloud infrastructure generally
>> > provide an ability to customize SecureBoot variables, in
>> > particular, it is possible to bring your own SecureBoot 'db'. This
>> > may come handy when a user wants to load a third party kernel
>> > module (self built or provided by a third party vendor) while still
>> > using a distro provided kernel. Generally, distro provided kernels
>> > sign modules with an ephemeral key and discard the private part
>> > during the build. While MOK can sometimes be used to sign something
>> > out-of-tree, it is a tedious process requiring either a manual
>> > intervention with shim or a 'certmule' (see
>> > https://blogs.oracle.com/linux/post/the-machine-keyring). In
>> > contrast, the beauty of using SecureBoot 'db' in this scenario is
>> > that for public clouds and virtualized infrastructure it is
>> > normally a property of the OS image (or the whole
>> > infrastructure/host) and not an individual instance; this means
>> > that all instances created from the same template will have 'db'
>> > keys in '.platform' by default.
>> 
>> Hasn’t this approach been rejected multiple times in the past?
>
> Well not rejected, just we always thought that people (like me) who
> take control of their secure boot systems are a tiny minority who can
> cope with being different.  I have to say the embedding of all the
> variable manipulations in shim made it quite hard.  However you can use
> the efitools KeyTool to get a graphical method for adding MoK keys even
> in the absence of shim.
>
> The question is, is there a growing use case for db users beyond the
> exceptions who own their own keys on their laptop, in which case we
> should reconsider this.

Yes, exactly; I may had missed some of the discussions but what I found
gave me the impression that the idea was never implemented just because
'db' was normally considered to be outside of user's control ("just a few
evil certs from MS"). This may still be true for bare metal but over the
last few years things have changed in a way that major cloud providers
started moving towards offering UEFI booted instances by default (or, in
some cases, UEFI-only instances). At least the three major hyperscalers
(AWS, GCP, Azure) offer fairly straightforward ways to customize 'db'
for SecureBoot; it is also possible to have a custom UEFI setup with
KVM/QEMU+OVMF based infrastructures. 

'certwrapper' offers _a_ solution which is great. It may, however, not
be very convenient to use when a user wants to re-use the same OS image
(e.g. provided by the distro vendor) for various different use-cases as
proper 'certwrapper' binary needs to be placed on the ESP (and thus
we'll end up with a bunch of images instead of one). 'db' is different
because it normally lives outside of the OS disk so it is possible to
register the exact same OS image with different properties (e.g. with
and without a custom cert which allows to load third party modules).

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.

-- 
Vitaly

> On Jun 5, 2025, at 1:54 AM, Vitaly Kuznetsov <vkuznets@redhat.com> wrote:
> 
> 'certwrapper' offers _a_ solution which is great. It may, however, not
> be very convenient to use when a user wants to re-use the same OS image
> (e.g. provided by the distro vendor) for various different use-cases as
> proper 'certwrapper' binary needs to be placed on the ESP (and thus
> we'll end up with a bunch of images instead of one). 'db' is different
> because it normally lives outside of the OS disk so it is possible to
> register the exact same OS image with different properties (e.g. with
> and without a custom cert which allows to load third party modules).

Could you please provide more details? The kernel module is signed with 
a specific key. The ‘db’  key in the cloud image must match whatever key 
was used to sign the kernel module.

Why can’t the RPM package that contains the kernel module also include 
the required ‘certwrapper’? When the RPM is installed, the appropriate 
‘certwrapper’ is placed on the ESP.  There can be any number of 'certwrappers' 
in the ESP. Doesn’t this solution address the issue?

Eric Snowberg <eric.snowberg@oracle.com> writes:

>> On Jun 5, 2025, at 1:54 AM, Vitaly Kuznetsov <vkuznets@redhat.com> wrote:
>> 
>> 'certwrapper' offers _a_ solution which is great. It may, however, not
>> be very convenient to use when a user wants to re-use the same OS image
>> (e.g. provided by the distro vendor) for various different use-cases as
>> proper 'certwrapper' binary needs to be placed on the ESP (and thus
>> we'll end up with a bunch of images instead of one). 'db' is different
>> because it normally lives outside of the OS disk so it is possible to
>> register the exact same OS image with different properties (e.g. with
>> and without a custom cert which allows to load third party modules).
>
> Could you please provide more details? The kernel module is signed with 
> a specific key. The ‘db’  key in the cloud image must match whatever key 
> was used to sign the kernel module.
>
> Why can’t the RPM package that contains the kernel module also include 
> the required ‘certwrapper’?  When the RPM is installed, the appropriate 
> ‘certwrapper’ is placed on the ESP.  There can be any number of 'certwrappers' 
> in the ESP. Doesn’t this solution address the issue?

I think it does but let me elaborate on where I believe some (minor?)
inconvenience comes from.

We have various actors here:
1) The OS image which is coming from a distro vendor.

2) The user, which takes the OS image and registers it with specific
properties (including 'db') with various infrastructures (e.g. different
clouds).

3) A third party kmod vendor which produces a module compatible with the
OS version. The module may only make sense for certain VMs on certain
clouds.

The customization of the VM normally happens upon first boot: a generic
image from the OS vendor (1) boots and then some provisioning agent
(cloud-init, WALA,...) takes over and e.g. installs additional
stuff. This additional stuff may include third party kmods from (3).

The 'certwrapper' must carry the key which the third party vendor (3) uses
and it must be signed by a key which the user (2) put to the 'db'. If we
want to have the 'certwrapper' shipped inside the same RPM as the kernel
module, it will be signed by the same third party vendor (3). While this
looks a bit weird ('self-signed certwrapper'), I don't see why this
can't work. 

Besides the need to teach (3) how to build certwrappers, an inconvenience
in this scheme comes from the fact that to activate a 'certwrapper'
which we install from a custom rpm, we need a reboot. Cloud instances
often back burstable workloads and this can be seen as annoyance.

-- 
Vitaly

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.boccassi@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.
'
Regards,

James

James Bottomley <James.Bottomley@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.boccassi@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

On Thu, 2025-06-05 at 15:43 +0200, Vitaly Kuznetsov wrote:
> James Bottomley <James.Bottomley@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.boccassi@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.

Well, not sure about that specific variable.  It seems to be set but
not used by shim (however it is used in the kernel to decide whether to
import the MoK list), so how would someone with a current distrusted db
get it set?  But there's also MokIgnoreDB (which is actually a RT
import of MokDBState) which is used to prevent importing the db certs
into the platform keyring in the first place.

I think the reason this is so fragmented is because we didn't really
co-ordinate with shim when all the variables and switches were added. 
Perhaps we should document all the variables and expectations before
deciding on a mechanism? 

The one thing we can guarantee is if the cloud use case is booting
without shim (is it?) then none of the RT variables will get created,
so checking any (or a set) of them would work.

> 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.

I'm less keen on user specifiable runtime because the security policy
of the system using a lockdown to make root less privileged than ring 0
can't allow a malicious root to weaken it.  However, let's see if we
can get a proposal that would mitigate that concern.

Ideally, if we can get to something that works for everyone at runtime,
we can remove the current Kconfig explosion which is definitely adding
to the confusion (as shown in the Debian bug reports).

Regards,

James

James Bottomley <James.Bottomley@HansenPartnership.com> writes:

> On Thu, 2025-06-05 at 15:43 +0200, Vitaly Kuznetsov wrote:
>> James Bottomley <James.Bottomley@HansenPartnership.com> writes:
>> 
>> > On Thu, 2025-06-05 at 09:54 +0200, Vitaly Kuznetsov wrote:
>> 
>> 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.
>
> Well, not sure about that specific variable.  It seems to be set but
> not used by shim (however it is used in the kernel to decide whether to
> import the MoK list), so how would someone with a current distrusted db
> get it set?  But there's also MokIgnoreDB (which is actually a RT
> import of MokDBState) which is used to prevent importing the db certs
> into the platform keyring in the first place.
>
> I think the reason this is so fragmented is because we didn't really
> co-ordinate with shim when all the variables and switches were added. 
> Perhaps we should document all the variables and expectations before
> deciding on a mechanism? 

I was hoping Peter (pjones@) can help us here) Generally, I agree that
as these variables originate in shim, we should describe them there and
not try to give them some potentially undesired meaning in kernel.

>
> The one thing we can guarantee is if the cloud use case is booting
> without shim (is it?) then none of the RT variables will get created,
> so checking any (or a set) of them would work.

Personally, I always advocate for injecting shim in the boot chain at
least when distro kernels are used: shim provides SBAT revocation
mechanism which is likely going to be used when a new secureboot related
vulnerability is discovered. SBAT was used for UKIs only but a mechanism
for embedding it into the Linux kernel itself is coming (already merged
for 'zboot' arches, pending for x86). If, however, someone is signing
his own kernels and can use 'dbx' or even revoke the cert in case of a
problem, then I guess shim can be avoided.

>> 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.
>
> I'm less keen on user specifiable runtime because the security policy
> of the system using a lockdown to make root less privileged than ring 0
> can't allow a malicious root to weaken it.  However, let's see if we
> can get a proposal that would mitigate that concern.
>
> Ideally, if we can get to something that works for everyone at runtime,
> we can remove the current Kconfig explosion which is definitely adding
> to the confusion (as shown in the Debian bug reports).

-- 
Vitaly