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

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

[Vitaly Kuznetsov]

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

[PATCH RFC 1/1] module: Make use of platform keyring for module signature verify

[Vitaly Kuznetsov]

This patch complements commit 278311e417be ("kexec, KEYS: Make use of
platform keyring for signature verify") and commit 6fce1f40e951
("dm verity: add support for signature verification with platform keyring")
and allows for signing modules using keys from SecureBoot 'db'. This may
come handy when the user has control over it, e.g. in a virtualized or a
cloud environment.

Suggested-by: Robert Holmes <robeholmes@gmail.com>
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 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(-)

diff --git a/Documentation/admin-guide/module-signing.rst b/Documentation/admin-guide/module-signing.rst
index a8667a777490..44ed93e586b9 100644
--- a/Documentation/admin-guide/module-signing.rst
+++ b/Documentation/admin-guide/module-signing.rst
@@ -118,6 +118,12 @@ This has a number of options available:
      additional certificates which will be included in the system keyring by
      default.
 
+ (5) :menuselection:`Use .platform keyring for verifying kernel modules signatures`
+     (``CONFIG_MODULE_SIG_PLATFORM``)
+
+     This option additionally allows modules to be signed with a key present
+     in ``.platform`` keyring, e.g. a SecureBoot 'db' key.
+
 Note that enabling module signing adds a dependency on the OpenSSL devel
 packages to the kernel build processes for the tool that does the signing.
 
diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig
index 39278737bb68..f1b85c14548a 100644
--- a/kernel/module/Kconfig
+++ b/kernel/module/Kconfig
@@ -340,6 +340,17 @@ config MODULE_SIG_HASH
 	default "sha3-384" if MODULE_SIG_SHA3_384
 	default "sha3-512" if MODULE_SIG_SHA3_512
 
+config MODULE_SIG_PLATFORM
+	bool "Use .platform keyring for verifying kernel modules signatures"
+	depends on INTEGRITY_PLATFORM_KEYRING
+	depends on MODULE_SIG
+	help
+	  When selected, keys from .platform keyring can be used for verifying
+	  modules signatures. In particular, this allows to use UEFI SecureBoot
+	  'db' for verification.
+
+	  If unsure, say N.
+
 config MODULE_COMPRESS
 	bool "Module compression"
 	help
diff --git a/kernel/module/signing.c b/kernel/module/signing.c
index a2ff4242e623..3327e7243211 100644
--- a/kernel/module/signing.c
+++ b/kernel/module/signing.c
@@ -61,10 +61,17 @@ int mod_verify_sig(const void *mod, struct load_info *info)
 	modlen -= sig_len + sizeof(ms);
 	info->len = modlen;
 
-	return verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len,
+	ret = verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len,
 				      VERIFY_USE_SECONDARY_KEYRING,
 				      VERIFYING_MODULE_SIGNATURE,
 				      NULL, NULL);
+	if (ret == -ENOKEY && IS_ENABLED(CONFIG_MODULE_SIG_PLATFORM)) {
+		ret = verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len,
+				VERIFY_USE_PLATFORM_KEYRING,
+				VERIFYING_MODULE_SIGNATURE,
+				NULL, NULL);
+	}
+	return ret;
 }
 
 int module_sig_check(struct load_info *info, int flags)
diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig
index 3c45f4f3455f..b7fa83d37a01 100644
--- a/security/integrity/Kconfig
+++ b/security/integrity/Kconfig
@@ -60,7 +60,7 @@ config INTEGRITY_PLATFORM_KEYRING
 	  Provide a separate, distinct keyring for platform trusted keys, which
 	  the kernel automatically populates during initialization from values
 	  provided by the platform for verifying the kexec'ed kerned image
-	  and, possibly, the initramfs signature.
+	  and, possibly, the initramfs signature and kernel modules signatures.
 
 config INTEGRITY_MACHINE_KEYRING
 	bool "Provide a keyring to which Machine Owner Keys may be added"
-- 
2.49.0

Re: [PATCH RFC 1/1] module: Make use of platform keyring for module signature verify

[James Bottomley]

On Mon, 2025-06-02 at 15:25 +0200, Vitaly Kuznetsov wrote:
> This patch complements commit 278311e417be ("kexec, KEYS: Make use of
> platform keyring for signature verify") and commit 6fce1f40e951
> ("dm verity: add support for signature verification with platform
> keyring")
> and allows for signing modules using keys from SecureBoot 'db'. This
> may
> come handy when the user has control over it, e.g. in a virtualized
> or a
> cloud environment.
> 
> Suggested-by: Robert Holmes <robeholmes@gmail.com>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
>  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(-)
> 
> diff --git a/Documentation/admin-guide/module-signing.rst
> b/Documentation/admin-guide/module-signing.rst
> index a8667a777490..44ed93e586b9 100644
> --- a/Documentation/admin-guide/module-signing.rst
> +++ b/Documentation/admin-guide/module-signing.rst
> @@ -118,6 +118,12 @@ This has a number of options available:
>       additional certificates which will be included in the system
> keyring by
>       default.
>  
> + (5) :menuselection:`Use .platform keyring for verifying kernel
> modules signatures`
> +     (``CONFIG_MODULE_SIG_PLATFORM``)
> +
> +     This option additionally allows modules to be signed with a key
> present
> +     in ``.platform`` keyring, e.g. a SecureBoot 'db' key.
> +
>  Note that enabling module signing adds a dependency on the OpenSSL
> devel
>  packages to the kernel build processes for the tool that does the
> signing.
>  
> diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig
> index 39278737bb68..f1b85c14548a 100644
> --- a/kernel/module/Kconfig
> +++ b/kernel/module/Kconfig
> @@ -340,6 +340,17 @@ config MODULE_SIG_HASH
>  	default "sha3-384" if MODULE_SIG_SHA3_384
>  	default "sha3-512" if MODULE_SIG_SHA3_512
>  
> +config MODULE_SIG_PLATFORM
> +	bool "Use .platform keyring for verifying kernel modules
> signatures"
> +	depends on INTEGRITY_PLATFORM_KEYRING
> +	depends on MODULE_SIG
> +	help
> +	  When selected, keys from .platform keyring can be used for
> verifying
> +	  modules signatures. In particular, this allows to use UEFI
> SecureBoot
> +	  'db' for verification.
> +
> +	  If unsure, say N.
> +
>  config MODULE_COMPRESS
>  	bool "Module compression"
>  	help
> diff --git a/kernel/module/signing.c b/kernel/module/signing.c
> index a2ff4242e623..3327e7243211 100644
> --- a/kernel/module/signing.c
> +++ b/kernel/module/signing.c
> @@ -61,10 +61,17 @@ int mod_verify_sig(const void *mod, struct
> load_info *info)
>  	modlen -= sig_len + sizeof(ms);
>  	info->len = modlen;
>  
> -	return verify_pkcs7_signature(mod, modlen, mod + modlen,
> sig_len,
> +	ret = verify_pkcs7_signature(mod, modlen, mod + modlen,
> sig_len,
>  				      VERIFY_USE_SECONDARY_KEYRING,
>  				      VERIFYING_MODULE_SIGNATURE,
>  				      NULL, NULL);
> +	if (ret == -ENOKEY &&
> IS_ENABLED(CONFIG_MODULE_SIG_PLATFORM)) {
> +		ret = verify_pkcs7_signature(mod, modlen, mod +
> modlen, sig_len,
> +				VERIFY_USE_PLATFORM_KEYRING,
> +				VERIFYING_MODULE_SIGNATURE,
> +				NULL, NULL);
> +	}
> +	return ret;
>  }

I don't think this is the correct way to do it.  If, as you say, db is
controlled by the end user and therefore has trusted contents, then I
think you want to update certs/system_keyring.c to link the platform
keyring into the secondary trusted one (like it does today for the
machine keyring), so it can be used by *every* application that checks
keyrings rather than just modules.

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.

Regards,

James

Re: [PATCH RFC 1/1] module: Make use of platform keyring for module signature verify

[Vitaly Kuznetsov]

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

> On Mon, 2025-06-02 at 15:25 +0200, Vitaly Kuznetsov wrote:
>> This patch complements commit 278311e417be ("kexec, KEYS: Make use of
>> platform keyring for signature verify") and commit 6fce1f40e951
>> ("dm verity: add support for signature verification with platform
>> keyring")
>> and allows for signing modules using keys from SecureBoot 'db'. This
>> may
>> come handy when the user has control over it, e.g. in a virtualized
>> or a
>> cloud environment.
>> 
>> Suggested-by: Robert Holmes <robeholmes@gmail.com>
>> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>> ---
>>  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(-)
>> 
>> diff --git a/Documentation/admin-guide/module-signing.rst
>> b/Documentation/admin-guide/module-signing.rst
>> index a8667a777490..44ed93e586b9 100644
>> --- a/Documentation/admin-guide/module-signing.rst
>> +++ b/Documentation/admin-guide/module-signing.rst
>> @@ -118,6 +118,12 @@ This has a number of options available:
>>       additional certificates which will be included in the system
>> keyring by
>>       default.
>>  
>> + (5) :menuselection:`Use .platform keyring for verifying kernel
>> modules signatures`
>> +     (``CONFIG_MODULE_SIG_PLATFORM``)
>> +
>> +     This option additionally allows modules to be signed with a key
>> present
>> +     in ``.platform`` keyring, e.g. a SecureBoot 'db' key.
>> +
>>  Note that enabling module signing adds a dependency on the OpenSSL
>> devel
>>  packages to the kernel build processes for the tool that does the
>> signing.
>>  
>> diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig
>> index 39278737bb68..f1b85c14548a 100644
>> --- a/kernel/module/Kconfig
>> +++ b/kernel/module/Kconfig
>> @@ -340,6 +340,17 @@ config MODULE_SIG_HASH
>>  	default "sha3-384" if MODULE_SIG_SHA3_384
>>  	default "sha3-512" if MODULE_SIG_SHA3_512
>>  
>> +config MODULE_SIG_PLATFORM
>> +	bool "Use .platform keyring for verifying kernel modules
>> signatures"
>> +	depends on INTEGRITY_PLATFORM_KEYRING
>> +	depends on MODULE_SIG
>> +	help
>> +	  When selected, keys from .platform keyring can be used for
>> verifying
>> +	  modules signatures. In particular, this allows to use UEFI
>> SecureBoot
>> +	  'db' for verification.
>> +
>> +	  If unsure, say N.
>> +
>>  config MODULE_COMPRESS
>>  	bool "Module compression"
>>  	help
>> diff --git a/kernel/module/signing.c b/kernel/module/signing.c
>> index a2ff4242e623..3327e7243211 100644
>> --- a/kernel/module/signing.c
>> +++ b/kernel/module/signing.c
>> @@ -61,10 +61,17 @@ int mod_verify_sig(const void *mod, struct
>> load_info *info)
>>  	modlen -= sig_len + sizeof(ms);
>>  	info->len = modlen;
>>  
>> -	return verify_pkcs7_signature(mod, modlen, mod + modlen,
>> sig_len,
>> +	ret = verify_pkcs7_signature(mod, modlen, mod + modlen,
>> sig_len,
>>  				      VERIFY_USE_SECONDARY_KEYRING,
>>  				      VERIFYING_MODULE_SIGNATURE,
>>  				      NULL, NULL);
>> +	if (ret == -ENOKEY &&
>> IS_ENABLED(CONFIG_MODULE_SIG_PLATFORM)) {
>> +		ret = verify_pkcs7_signature(mod, modlen, mod +
>> modlen, sig_len,
>> +				VERIFY_USE_PLATFORM_KEYRING,
>> +				VERIFYING_MODULE_SIGNATURE,
>> +				NULL, NULL);
>> +	}
>> +	return ret;
>>  }
>
> I don't think this is the correct way to do it.  If, as you say, db is
> controlled by the end user and therefore has trusted contents, then I
> think you want to update certs/system_keyring.c to link the platform
> keyring into the secondary trusted one (like it does today for the
> machine keyring), so it can be used by *every* application that checks
> keyrings rather than just modules.

Yea, that would be the solution I allude to at the end of my cover
letter: make .platform globally trusted so we don't need the 'trusted
for kexec', 'trusted for dm-verity' zoo we already have.

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

As part of the RFC, I'd like to try to understand under which conditions
people may not want to trust 'db'. In the most common use case, 'db' is
used to authorize shim and the kernel is signed by a cert from shim's
vendor_db, not trusting 'db' for modules after that seems somawhat
silly. Maybe we can detect the fact that the user took control over the
system with MOK and untrust .platform only then (while trusting it by
default)?

A runtime toggle is not something I thought much about: the sole purpose
of this part of 'lockdown' (limitimg unsigned modules load) seems to be
to prevent someone who already has 'root' on the system to gain kernel
level access to e.g. hide its activities. In case root can decide which
keys are trusted, isn't it all in vain? Or maybe if the toggle is to
just trust/not trust .platform (and not e.g. disable signatures
verification completely, inject a new key,...) this is acceptable?
Another option is to have a kernel command line parameter but this is
complicated for users.

-- 
Vitaly

Re: [PATCH RFC 1/1] module: Make use of platform keyring for module signature verify

[James Bottomley]

On Tue, 2025-06-03 at 10:52 +0200, Vitaly Kuznetsov wrote:
> James Bottomley <James.Bottomley@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.

> As part of the RFC, I'd like to try to understand under which
> conditions people may not want to trust 'db'. In the most common use
> case, 'db' is used to authorize shim and the kernel is signed by a
> cert from shim's vendor_db, not trusting 'db' for modules after that
> seems somawhat silly. Maybe we can detect the fact that the user took
> control over the system with MOK and untrust .platform only then
> (while trusting it by default)?

Well, I think it's pretty obvious that in a standard secure boot system
most people wouldn't want either Microsoft or the ODM manufacturer
being in a position to sign module code for their systems.  Indeed,
when this was first mooted by Red Hat years ago, I thought Microsoft
refused to be the CA for our modules anyway.  From a security point of
view, it's separation of concerns: the standard secure boot database
guards access to the UEFI boot time before ExitBootServices.  The
kernel is a completely separate security domain and should be guarded
by different keys.

> A runtime toggle is not something I thought much about: the sole
> purpose of this part of 'lockdown' (limitimg unsigned modules load)
> seems to be to prevent someone who already has 'root' on the system
> to gain kernel level access to e.g. hide its activities. In case root
> can decide which keys are trusted, isn't it all in vain?

Not exactly, the purpose of lockdown is to make root less privileged
than ring 0 (the kernel), so that a user space privilege escalation
does less damage.  The gold standard for all of this is supposed to be
to foil an Evil Maid attack (physical access) but I don't think we're
quite there yet.  From the point of view of the keyrings a lot of
others (like .ima) have trusted signing requirements meaning root can't
simply add keys, they have to be signed by keys in the existing trusted
keyring as well.

>  Or maybe if the toggle is to just trust/not trust .platform (and not
> e.g. disable signatures verification completely, inject a new
> key,...) this is acceptable? Another option is to have a kernel
> command line parameter but this is complicated for users.

I was thinking that if the goal is simply to enable cloud db then the
toggle could be detecting the presence of the MoK variables.  However,
if the distro politics thought above is correct, that won't work for
the RH use case of enabling additional binary modules by getting others
to sign them.  Until we have UKI signing of the kernel command line,
it's not such a safe vector to use for switches like this because it
makes the Evil Maid problem worse (and they're hard for users to manage
anyway as you say).

Regards,

James

Re: [PATCH RFC 1/1] module: Make use of platform keyring for module signature verify

[Vitaly Kuznetsov]

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

> On Tue, 2025-06-03 at 10:52 +0200, Vitaly Kuznetsov wrote:
>> James Bottomley <James.Bottomley@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.
>

I guess such approach can be used with some limitations: the out-of-tree
module must be open source, the vendor of the module must commit to
fixing (inevitable) module build issues when the distro updates its
kernel and so on. It, however, doesn't help the users which want to
build and sign their own modules themselves.

>> As part of the RFC, I'd like to try to understand under which
>> conditions people may not want to trust 'db'. In the most common use
>> case, 'db' is used to authorize shim and the kernel is signed by a
>> cert from shim's vendor_db, not trusting 'db' for modules after that
>> seems somawhat silly. Maybe we can detect the fact that the user took
>> control over the system with MOK and untrust .platform only then
>> (while trusting it by default)?
>
> Well, I think it's pretty obvious that in a standard secure boot system
> most people wouldn't want either Microsoft or the ODM manufacturer
> being in a position to sign module code for their systems.  Indeed,
> when this was first mooted by Red Hat years ago, I thought Microsoft
> refused to be the CA for our modules anyway.  From a security point of
> view, it's separation of concerns: the standard secure boot database
> guards access to the UEFI boot time before ExitBootServices.  The
> kernel is a completely separate security domain and should be guarded
> by different keys.
>
>> A runtime toggle is not something I thought much about: the sole
>> purpose of this part of 'lockdown' (limitimg unsigned modules load)
>> seems to be to prevent someone who already has 'root' on the system
>> to gain kernel level access to e.g. hide its activities. In case root
>> can decide which keys are trusted, isn't it all in vain?
>
> Not exactly, the purpose of lockdown is to make root less privileged
> than ring 0 (the kernel), so that a user space privilege escalation
> does less damage.  The gold standard for all of this is supposed to be
> to foil an Evil Maid attack (physical access) but I don't think we're
> quite there yet.  From the point of view of the keyrings a lot of
> others (like .ima) have trusted signing requirements meaning root can't
> simply add keys, they have to be signed by keys in the existing trusted
> keyring as well.
>
>>  Or maybe if the toggle is to just trust/not trust .platform (and not
>> e.g. disable signatures verification completely, inject a new
>> key,...) this is acceptable? Another option is to have a kernel
>> command line parameter but this is complicated for users.
>
> I was thinking that if the goal is simply to enable cloud db then the
> toggle could be detecting the presence of the MoK variables.  However,
> if the distro politics thought above is correct, that won't work for
> the RH use case of enabling additional binary modules by getting others
> to sign them.  Until we have UKI signing of the kernel command line,
> it's not such a safe vector to use for switches like this because it
> makes the Evil Maid problem worse (and they're hard for users to manage
> anyway as you say).

(FWIW, RH-signed UKI is already present in RHEL/Fedora/derivatives along
with a set of good known UKI cmdline extentions ('fips=1',
'crashkernel=...',...) so adding e.g. 'platform_is_trusted=1' extension
*is* possible).

So if we consider trusting/not trusing platform to be a distro choice
("politics"), then I guess the suggested Kconfig approach may make
sense? I, however, quite like the idea to complement it with an
automatic toggle based on the MOK status: we can make the Kconfig a
tristate:
- Platform is never trusted (current approach)
- Platform is always trusted
- Platform is trused when MOK is not used
To me, this third option makes sense: if a user wants to take ownership
over the system, they can use MOK and sign the kernel itself and/or
out-of-tree modules with it. If the user doesn't care, then there's no
reason to not trust 'db'.

-- 
Vitaly

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

[Eric Snowberg]

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

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

[James Bottomley]

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

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

[Vitaly Kuznetsov]

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

Re: [PATCH RFC 1/1] module: Make use of platform keyring for module signature verify

[Coiby Xu]

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

Re: [PATCH RFC 1/1] module: Make use of platform keyring for module signature verify

[James Bottomley]

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@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/
> 

Well if you read the attached bug reports:

https://bugs.debian.org/935945
https://bugs.debian.org/1030200

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.

Regards,

James

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

[James Bottomley]

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

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

[Eric Snowberg]

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

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

[Vitaly Kuznetsov]

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

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

[Mimi Zohar]

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(-)
> 

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

[Vitaly Kuznetsov]

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

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

[James Bottomley]

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

Re: [PATCH RFC 1/1] module: Make use of platform keyring for module signature verify

[Coiby Xu]

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@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/
>>
>
>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

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

[Vitaly Kuznetsov]

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