[PATCH v3 0/9] module: Introduce hash-based integrity checking

[PATCH v3 0/9] module: Introduce hash-based integrity checking

[Thomas Weißschuh]

The current signature-based module integrity checking has some drawbacks
in combination with reproducible builds:
Either the module signing key is generated at build time, which makes
the build unreproducible, or a static key is used, which precludes
rebuilds by third parties and makes the whole build and packaging
process much more complicated.
Introduce a new mechanism to ensure only well-known modules are loaded
by embedding a list of hashes of all modules built as part of the full
kernel build into vmlinux.

Interest has been proclaimed by NixOS, Arch Linux, Proxmox, SUSE and the
general reproducible builds community.

To properly test the reproducibility in combination with CONFIG_INFO_BTF
another patch or pahole v1.29 is needed:
"[PATCH bpf-next] kbuild, bpf: Enable reproducible BTF generation" [0]

Questions for current patch:
* Naming
* Can the number of built-in modules be retrieved while building
  kernel/module/hashes.o? This would remove the need for the
  preallocation step in link-vmlinux.sh.
* How should this interaction with IMA?

Further improvements:
* Use a LSM/IMA Keyring to store and validate hashes
* Use MODULE_SIG_HASH for configuration
* UAPI for discovery?
* Currently has a permanent memory overhead

[0] https://lore.kernel.org/lkml/20241211-pahole-reproducible-v1-1-22feae19bad9@weissschuh.net/

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
Changes in v3:
- Rebase on v6.15-rc1
- Use openssl to calculate hash
- Avoid warning if no modules are built
- Simplify module_integrity_check() a bit
- Make incompatibility with INSTALL_MOD_STRIP explicit
- Update docs
- Add IMA cleanups
- Link to v2: https://lore.kernel.org/r/20250120-module-hashes-v2-0-ba1184e27b7f@weissschuh.net

Changes in v2:
- Drop RFC state
- Mention interested parties in cover letter
- Expand Kconfig description
- Add compatibility with CONFIG_MODULE_SIG
- Parallelize module-hashes.sh
- Update Documentation/kbuild/reproducible-builds.rst
- Link to v1: https://lore.kernel.org/r/20241225-module-hashes-v1-0-d710ce7a3fd1@weissschuh.net

---
Thomas Weißschuh (9):
      powerpc/ima: Drop unnecessary check for CONFIG_MODULE_SIG
      ima: efi: Drop unnecessary check for CONFIG_MODULE_SIG/CONFIG_KEXEC_SIG
      kbuild: add stamp file for vmlinux BTF data
      kbuild: generate module BTF based on vmlinux.unstripped
      module: Make module loading policy usable without MODULE_SIG
      module: Move integrity checks into dedicated function
      module: Move lockdown check into generic module loader
      lockdown: Make the relationship to MODULE_SIG a dependency
      module: Introduce hash-based integrity checking

 .gitignore                                   |  1 +
 Documentation/kbuild/reproducible-builds.rst |  5 ++-
 Makefile                                     |  8 +++-
 arch/powerpc/kernel/ima_arch.c               |  3 +-
 include/asm-generic/vmlinux.lds.h            | 11 ++++++
 include/linux/module.h                       |  8 ++--
 include/linux/module_hashes.h                | 17 +++++++++
 kernel/module/Kconfig                        | 21 ++++++++++-
 kernel/module/Makefile                       |  1 +
 kernel/module/hashes.c                       | 56 ++++++++++++++++++++++++++++
 kernel/module/internal.h                     |  8 +---
 kernel/module/main.c                         | 51 ++++++++++++++++++++++---
 kernel/module/signing.c                      | 24 +-----------
 scripts/Makefile.modfinal                    | 18 ++++++---
 scripts/Makefile.modinst                     |  4 ++
 scripts/Makefile.vmlinux                     |  5 +++
 scripts/link-vmlinux.sh                      | 31 ++++++++++++++-
 scripts/module-hashes.sh                     | 26 +++++++++++++
 security/integrity/ima/ima_efi.c             |  6 +--
 security/lockdown/Kconfig                    |  2 +-
 20 files changed, 250 insertions(+), 56 deletions(-)
---
base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8
change-id: 20241225-module-hashes-7a50a7cc2a30

Best regards,
-- 
Thomas Weißschuh <linux@weissschuh.net>

[PATCH v3 1/9] powerpc/ima: Drop unnecessary check for CONFIG_MODULE_SIG

[Thomas Weißschuh]

When CONFIG_MODULE_SIG is disabled set_module_sig_enforced() is defined
as an empty stub, so the check is unnecessary.
The specific configuration option for set_module_sig_enforced() is
about to change and removing the check avoids some later churn.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>

---
This patch is not strictly necessary right now, but makes looking for
usages of CONFIG_MODULE_SIG easier.
---
 arch/powerpc/kernel/ima_arch.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/ima_arch.c b/arch/powerpc/kernel/ima_arch.c
index b7029beed847dc0acf15b3edbdd7fe9e60626f24..690263bf4265c78331b5f306097543ce12ac7dbd 100644
--- a/arch/powerpc/kernel/ima_arch.c
+++ b/arch/powerpc/kernel/ima_arch.c
@@ -63,8 +63,7 @@ static const char *const secure_and_trusted_rules[] = {
 const char *const *arch_get_ima_policy(void)
 {
 	if (is_ppc_secureboot_enabled()) {
-		if (IS_ENABLED(CONFIG_MODULE_SIG))
-			set_module_sig_enforced();
+		set_module_sig_enforced();
 
 		if (is_ppc_trustedboot_enabled())
 			return secure_and_trusted_rules;

-- 
2.49.0

Re: [PATCH v3 1/9] powerpc/ima: Drop unnecessary check for CONFIG_MODULE_SIG

[Mimi Zohar]

On Tue, 2025-04-29 at 15:04 +0200, Thomas Weißschuh wrote:
> When CONFIG_MODULE_SIG is disabled set_module_sig_enforced() is defined
> as an empty stub, so the check is unnecessary.
> The specific configuration option for set_module_sig_enforced() is
> about to change and removing the check avoids some later churn.
> 
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>

Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
> 
> ---
> This patch is not strictly necessary right now, but makes looking for
> usages of CONFIG_MODULE_SIG easier.
> ---
>  arch/powerpc/kernel/ima_arch.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/ima_arch.c b/arch/powerpc/kernel/ima_arch.c
> index b7029beed847dc0acf15b3edbdd7fe9e60626f24..690263bf4265c78331b5f306097543ce12ac7dbd
> 100644
> --- a/arch/powerpc/kernel/ima_arch.c
> +++ b/arch/powerpc/kernel/ima_arch.c
> @@ -63,8 +63,7 @@ static const char *const secure_and_trusted_rules[] = {
>  const char *const *arch_get_ima_policy(void)
>  {
>  	if (is_ppc_secureboot_enabled()) {
> -		if (IS_ENABLED(CONFIG_MODULE_SIG))
> -			set_module_sig_enforced();
> +		set_module_sig_enforced();
>  
>  		if (is_ppc_trustedboot_enabled())
>  			return secure_and_trusted_rules;
> 

[PATCH v3 2/9] ima: efi: Drop unnecessary check for CONFIG_MODULE_SIG/CONFIG_KEXEC_SIG

[Thomas Weißschuh]

When configuration settings are disabled the guarded functions are
defined as empty stubs, so the check is unnecessary.
The specific configuration option for set_module_sig_enforced() is
about to change and removing the checks avoids some later churn.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>

---
This patch is not strictly necessary right now, but makes looking for
usages of CONFIG_MODULE_SIG easier.
---
 security/integrity/ima/ima_efi.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/security/integrity/ima/ima_efi.c b/security/integrity/ima/ima_efi.c
index 138029bfcce1e40ef37700c15e30909f6e9b4f2d..a35dd166ad47beb4a7d46cc3e8fc604f57e03ecb 100644
--- a/security/integrity/ima/ima_efi.c
+++ b/security/integrity/ima/ima_efi.c
@@ -68,10 +68,8 @@ static const char * const sb_arch_rules[] = {
 const char * const *arch_get_ima_policy(void)
 {
 	if (IS_ENABLED(CONFIG_IMA_ARCH_POLICY) && arch_ima_get_secureboot()) {
-		if (IS_ENABLED(CONFIG_MODULE_SIG))
-			set_module_sig_enforced();
-		if (IS_ENABLED(CONFIG_KEXEC_SIG))
-			set_kexec_sig_enforced();
+		set_module_sig_enforced();
+		set_kexec_sig_enforced();
 		return sb_arch_rules;
 	}
 	return NULL;

-- 
2.49.0

Re: [PATCH v3 2/9] ima: efi: Drop unnecessary check for CONFIG_MODULE_SIG/CONFIG_KEXEC_SIG

[Mimi Zohar]

On Tue, 2025-04-29 at 15:04 +0200, Thomas Weißschuh wrote:
> When configuration settings are disabled the guarded functions are
> defined as empty stubs, so the check is unnecessary.
> The specific configuration option for set_module_sig_enforced() is
> about to change and removing the checks avoids some later churn.
> 
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> 
> ---
> This patch is not strictly necessary right now, but makes looking for
> usages of CONFIG_MODULE_SIG easier.
> ---
>  security/integrity/ima/ima_efi.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/security/integrity/ima/ima_efi.c b/security/integrity/ima/ima_efi.c
> index
> 138029bfcce1e40ef37700c15e30909f6e9b4f2d..a35dd166ad47beb4a7d46cc3e8fc604f57e03ecb
> 100644
> --- a/security/integrity/ima/ima_efi.c
> +++ b/security/integrity/ima/ima_efi.c
> @@ -68,10 +68,8 @@ static const char * const sb_arch_rules[] = {
>  const char * const *arch_get_ima_policy(void)
>  {
>  	if (IS_ENABLED(CONFIG_IMA_ARCH_POLICY) && arch_ima_get_secureboot()) {
> -		if (IS_ENABLED(CONFIG_MODULE_SIG))
> -			set_module_sig_enforced();
> -		if (IS_ENABLED(CONFIG_KEXEC_SIG))
> -			set_kexec_sig_enforced();
> +		set_module_sig_enforced();
> +		set_kexec_sig_enforced();
>  		return sb_arch_rules;

Hi Thomas,

I'm just getting to looking at this patch set.  Sorry for the delay.

Testing whether CONFIG_MODULE_SIG and CONFIG_KEXEC_SIG are configured gives priority
to them, rather than to the IMA support.  Without any other changes, both signature
verifications would be enforced.  Is that the intention?

Mimi

>  	}
>  	return NULL;
> 

Re: [PATCH v3 2/9] ima: efi: Drop unnecessary check for CONFIG_MODULE_SIG/CONFIG_KEXEC_SIG

[Mimi Zohar]

On Wed, 2025-05-14 at 11:09 -0400, Mimi Zohar wrote:
> On Tue, 2025-04-29 at 15:04 +0200, Thomas Weißschuh wrote:
> > When configuration settings are disabled the guarded functions are
> > defined as empty stubs, so the check is unnecessary.
> > The specific configuration option for set_module_sig_enforced() is
> > about to change and removing the checks avoids some later churn.
> > 
> > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> > 
> > ---
> > This patch is not strictly necessary right now, but makes looking for
> > usages of CONFIG_MODULE_SIG easier.
> > ---
> >  security/integrity/ima/ima_efi.c | 6 ++----
> >  1 file changed, 2 insertions(+), 4 deletions(-)
> > 
> > diff --git a/security/integrity/ima/ima_efi.c b/security/integrity/ima/ima_efi.c
> > index
> > 138029bfcce1e40ef37700c15e30909f6e9b4f2d..a35dd166ad47beb4a7d46cc3e8fc604f57e03ecb
> > 100644
> > --- a/security/integrity/ima/ima_efi.c
> > +++ b/security/integrity/ima/ima_efi.c
> > @@ -68,10 +68,8 @@ static const char * const sb_arch_rules[] = {
> >  const char * const *arch_get_ima_policy(void)
> >  {
> >  	if (IS_ENABLED(CONFIG_IMA_ARCH_POLICY) && arch_ima_get_secureboot()) {
> > -		if (IS_ENABLED(CONFIG_MODULE_SIG))
> > -			set_module_sig_enforced();
> > -		if (IS_ENABLED(CONFIG_KEXEC_SIG))
> > -			set_kexec_sig_enforced();
> > +		set_module_sig_enforced();
> > +		set_kexec_sig_enforced();
> >  		return sb_arch_rules;
> 
> Hi Thomas,
> 
> I'm just getting to looking at this patch set.  Sorry for the delay.
> 
> Testing whether CONFIG_MODULE_SIG and CONFIG_KEXEC_SIG are configured gives priority
> to them, rather than to the IMA support.  Without any other changes, both signature
> verifications would be enforced.  Is that the intention?

Never mind, got it.

Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>

Re: [PATCH v3 2/9] ima: efi: Drop unnecessary check for CONFIG_MODULE_SIG/CONFIG_KEXEC_SIG

[Thomas Weißschuh]

May 14, 2025 19:39:37 Mimi Zohar <zohar@linux.ibm.com>:

> On Wed, 2025-05-14 at 11:09 -0400, Mimi Zohar wrote:
>> On Tue, 2025-04-29 at 15:04 +0200, Thomas Weißschuh wrote:
>>> When configuration settings are disabled the guarded functions are
>>> defined as empty stubs, so the check is unnecessary.
>>> The specific configuration option for set_module_sig_enforced() is
>>> about to change and removing the checks avoids some later churn.
>>>
>>> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
>>>
>>> ---
>>> This patch is not strictly necessary right now, but makes looking for
>>> usages of CONFIG_MODULE_SIG easier.
>>> ---
>>>  security/integrity/ima/ima_efi.c | 6 ++----
>>>  1 file changed, 2 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/security/integrity/ima/ima_efi.c b/security/integrity/ima/ima_efi.c
>>> index
>>> 138029bfcce1e40ef37700c15e30909f6e9b4f2d..a35dd166ad47beb4a7d46cc3e8fc604f57e03ecb
>>> 100644
>>> --- a/security/integrity/ima/ima_efi.c
>>> +++ b/security/integrity/ima/ima_efi.c
>>> @@ -68,10 +68,8 @@ static const char * const sb_arch_rules[] = {
>>>  const char * const *arch_get_ima_policy(void)
>>>  {
>>>     if (IS_ENABLED(CONFIG_IMA_ARCH_POLICY) && arch_ima_get_secureboot()) {
>>> -       if (IS_ENABLED(CONFIG_MODULE_SIG))
>>> -           set_module_sig_enforced();
>>> -       if (IS_ENABLED(CONFIG_KEXEC_SIG))
>>> -           set_kexec_sig_enforced();
>>> +       set_module_sig_enforced();
>>> +       set_kexec_sig_enforced();
>>>         return sb_arch_rules;
>>
>> Hi Thomas,
>>
>> I'm just getting to looking at this patch set.  Sorry for the delay.
>>
>> Testing whether CONFIG_MODULE_SIG and CONFIG_KEXEC_SIG are configured gives priority
>> to them, rather than to the IMA support.  Without any other changes, both signature
>> verifications would be enforced.  Is that the intention?
>
> Never mind, got it.
>
> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>

Thanks for the review!

Given that this series has no chance
of getting into the next merge window,
would it be possible to take the two IMA preparation patches
through the IMA tree to have them out of the way?


Thomas

Re: [PATCH v3 2/9] ima: efi: Drop unnecessary check for CONFIG_MODULE_SIG/CONFIG_KEXEC_SIG

[Mimi Zohar]

On Wed, 2025-05-14 at 20:25 +0200, Thomas Weißschuh wrote:
> May 14, 2025 19:39:37 Mimi Zohar <zohar@linux.ibm.com>:
> 
> > On Wed, 2025-05-14 at 11:09 -0400, Mimi Zohar wrote:
> > > On Tue, 2025-04-29 at 15:04 +0200, Thomas Weißschuh wrote:
> > > > When configuration settings are disabled the guarded functions are
> > > > defined as empty stubs, so the check is unnecessary.
> > > > The specific configuration option for set_module_sig_enforced() is
> > > > about to change and removing the checks avoids some later churn.
> > > > 
> > > > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> > > > 
> > > > ---
> > > > This patch is not strictly necessary right now, but makes looking for
> > > > usages of CONFIG_MODULE_SIG easier.
> > > > ---
> > > >  security/integrity/ima/ima_efi.c | 6 ++----
> > > >  1 file changed, 2 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/security/integrity/ima/ima_efi.c b/security/integrity/ima/ima_efi.c
> > > > index
> > > > 138029bfcce1e40ef37700c15e30909f6e9b4f2d..a35dd166ad47beb4a7d46cc3e8fc604f57e03ecb
> > > > 100644
> > > > --- a/security/integrity/ima/ima_efi.c
> > > > +++ b/security/integrity/ima/ima_efi.c
> > > > @@ -68,10 +68,8 @@ static const char * const sb_arch_rules[] = {
> > > >  const char * const *arch_get_ima_policy(void)
> > > >  {
> > > >     if (IS_ENABLED(CONFIG_IMA_ARCH_POLICY) && arch_ima_get_secureboot()) {
> > > > -       if (IS_ENABLED(CONFIG_MODULE_SIG))
> > > > -           set_module_sig_enforced();
> > > > -       if (IS_ENABLED(CONFIG_KEXEC_SIG))
> > > > -           set_kexec_sig_enforced();
> > > > +       set_module_sig_enforced();
> > > > +       set_kexec_sig_enforced();
> > > >         return sb_arch_rules;
> > > 
> > > Hi Thomas,
> > > 
> > > I'm just getting to looking at this patch set.  Sorry for the delay.
> > > 
> > > Testing whether CONFIG_MODULE_SIG and CONFIG_KEXEC_SIG are configured gives priority
> > > to them, rather than to the IMA support.  Without any other changes, both signature
> > > verifications would be enforced.  Is that the intention?
> > 
> > Never mind, got it.
> > 
> > Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
> 
> Thanks for the review!
> 
> Given that this series has no chance
> of getting into the next merge window,
> would it be possible to take the two IMA preparation patches
> through the IMA tree to have them out of the way?

I'm fine with picking up the two patches simply as code cleanup, meaning dropping the last
sentence of the patch description, after some testing.

Mimi

[PATCH v3 3/9] kbuild: add stamp file for vmlinux BTF data

[Thomas Weißschuh]

The upcoming module hashes functionality will build the modules in
between the generation of the BTF data and the final link of vmlinux.
Having a dependency from the modules on vmlinux would make this
impossible as it would mean having a cyclic dependency.
Break this cyclic dependency by introducing a new target.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
 scripts/Makefile.modfinal | 4 ++--
 scripts/link-vmlinux.sh   | 6 ++++++
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/scripts/Makefile.modfinal b/scripts/Makefile.modfinal
index 542ba462ed3ec9607e0df10e26613a4c7ac318e8..5d01b553ec9a4565c8e5a6edd05665c409003bc1 100644
--- a/scripts/Makefile.modfinal
+++ b/scripts/Makefile.modfinal
@@ -52,8 +52,8 @@ if_changed_except = $(if $(call newer_prereqs_except,$(2))$(cmd-check),      \
 	printf '%s\n' 'savedcmd_$@ := $(make-cmd)' > $(dot-target).cmd, @:)
 
 # Re-generate module BTFs if either module's .ko or vmlinux changed
-%.ko: %.o %.mod.o .module-common.o $(objtree)/scripts/module.lds $(and $(CONFIG_DEBUG_INFO_BTF_MODULES),$(KBUILD_BUILTIN),$(objtree)/vmlinux) FORCE
-	+$(call if_changed_except,ld_ko_o,$(objtree)/vmlinux)
+%.ko: %.o %.mod.o .module-common.o $(objtree)/scripts/module.lds $(and $(CONFIG_DEBUG_INFO_BTF_MODULES),$(KBUILD_BUILTIN),$(objtree)/.tmp_vmlinux_btf.stamp) FORCE
+	+$(call if_changed_except,ld_ko_o,$(objtree)/.tmp_vmlinux_btf.stamp)
 ifdef CONFIG_DEBUG_INFO_BTF_MODULES
 	+$(if $(newer-prereqs),$(call cmd,btf_ko))
 endif
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index 51367c2bfc21ef9a8ebbc30670b1edd220b571a3..5f060787ce3fbcbcfdca0c95789d619e2a1c7b72 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -113,6 +113,7 @@ vmlinux_link()
 gen_btf()
 {
 	local btf_data=${1}.btf.o
+	local btf_stamp=.tmp_vmlinux_btf.stamp
 
 	info BTF "${btf_data}"
 	LLVM_OBJCOPY="${OBJCOPY}" ${PAHOLE} -J ${PAHOLE_FLAGS} ${1}
@@ -133,6 +134,11 @@ gen_btf()
 	fi
 	printf "${et_rel}" | dd of="${btf_data}" conv=notrunc bs=1 seek=16 status=none
 
+	info STAMP $btf_stamp
+	if ! cmp --silent $btf_data $btf_stamp; then
+		cp $btf_data $btf_stamp
+	fi
+
 	btf_vmlinux_bin_o=${btf_data}
 }
 

-- 
2.49.0

[PATCH v3 4/9] kbuild: generate module BTF based on vmlinux.unstripped

[Thomas Weißschuh]

The upcoming module hashes functionality will build the modules in
between the generation of the BTF data and the final link of vmlinux.
At this point vmlinux is not yet built and therefore can't be used for
module BTF generation. vmlinux.unstripped however is usable and
sufficient for BTF generation.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
 scripts/Makefile.modfinal | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/scripts/Makefile.modfinal b/scripts/Makefile.modfinal
index 5d01b553ec9a4565c8e5a6edd05665c409003bc1..527f6b27baff9db94d31c15447de445a05bc0634 100644
--- a/scripts/Makefile.modfinal
+++ b/scripts/Makefile.modfinal
@@ -36,11 +36,11 @@ quiet_cmd_ld_ko_o = LD [M]  $@
 
 quiet_cmd_btf_ko = BTF [M] $@
       cmd_btf_ko = 							\
-	if [ ! -f $(objtree)/vmlinux ]; then				\
-		printf "Skipping BTF generation for %s due to unavailability of vmlinux\n" $@ 1>&2; \
+	if [ ! -f $(objtree)/vmlinux.unstripped ]; then			\
+		printf "Skipping BTF generation for %s due to unavailability of vmlinux.unstripped\n" $@ 1>&2; \
 	else								\
-		LLVM_OBJCOPY="$(OBJCOPY)" $(PAHOLE) -J $(PAHOLE_FLAGS) $(MODULE_PAHOLE_FLAGS) --btf_base $(objtree)/vmlinux $@; \
-		$(RESOLVE_BTFIDS) -b $(objtree)/vmlinux $@;		\
+		LLVM_OBJCOPY="$(OBJCOPY)" $(PAHOLE) -J $(PAHOLE_FLAGS) $(MODULE_PAHOLE_FLAGS) --btf_base $(objtree)/vmlinux.unstripped $@; \
+		$(RESOLVE_BTFIDS) -b $(objtree)/vmlinux.unstripped $@;		\
 	fi;
 
 # Same as newer-prereqs, but allows to exclude specified extra dependencies

-- 
2.49.0

[PATCH v3 5/9] module: Make module loading policy usable without MODULE_SIG

[Thomas Weißschuh]

The loading policy functionality will also be used by the hash-based
module validation. Split it out from CONFIG_MODULE_SIG so it is usable
by both.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
 include/linux/module.h  |  8 ++++----
 kernel/module/Kconfig   |  6 +++++-
 kernel/module/main.c    | 26 +++++++++++++++++++++++++-
 kernel/module/signing.c | 21 ---------------------
 4 files changed, 34 insertions(+), 27 deletions(-)

diff --git a/include/linux/module.h b/include/linux/module.h
index d94b196d5a34e104d81308df4b150452eb96cdc9..68aa8bbd33acc84e013dc575ee88bd4e3101f9f4 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -453,7 +453,7 @@ struct module {
 	const u32 *gpl_crcs;
 	bool using_gplonly_symbols;
 
-#ifdef CONFIG_MODULE_SIG
+#ifdef CONFIG_MODULE_SIG_POLICY
 	/* Signature was verified. */
 	bool sig_ok;
 #endif
@@ -921,14 +921,14 @@ static inline bool retpoline_module_ok(bool has_retpoline)
 }
 #endif
 
-#ifdef CONFIG_MODULE_SIG
+#ifdef CONFIG_MODULE_SIG_POLICY
 bool is_module_sig_enforced(void);
 
 static inline bool module_sig_ok(struct module *module)
 {
 	return module->sig_ok;
 }
-#else	/* !CONFIG_MODULE_SIG */
+#else	/* !CONFIG_MODULE_SIG_POLICY */
 static inline bool is_module_sig_enforced(void)
 {
 	return false;
@@ -938,7 +938,7 @@ static inline bool module_sig_ok(struct module *module)
 {
 	return true;
 }
-#endif	/* CONFIG_MODULE_SIG */
+#endif	/* CONFIG_MODULE_SIG_POLICY */
 
 #if defined(CONFIG_MODULES) && defined(CONFIG_KALLSYMS)
 int module_kallsyms_on_each_symbol(const char *modname,
diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig
index c51f25538d0ea66e6486ad0be6684173cd0140b5..a3146e9378fcd3292a756a2a7ea5241524cbc408 100644
--- a/kernel/module/Kconfig
+++ b/kernel/module/Kconfig
@@ -265,9 +265,13 @@ config MODULE_SIG
 	  debuginfo strip done by some packagers (such as rpmbuild) and
 	  inclusion into an initramfs that wants the module size reduced.
 
+config MODULE_SIG_POLICY
+	def_bool y
+	depends on MODULE_SIG
+
 config MODULE_SIG_FORCE
 	bool "Require modules to be validly signed"
-	depends on MODULE_SIG
+	depends on MODULE_SIG_POLICY
 	help
 	  Reject unsigned modules or signed modules for which we don't have a
 	  key.  Without this, such modules will simply taint the kernel.
diff --git a/kernel/module/main.c b/kernel/module/main.c
index a2859dc3eea66ec19991e7e4afb5bbcae2c2d167..83c66205556fdde92152c131f1f58229c4f7f734 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -2432,7 +2432,7 @@ static void module_augment_kernel_taints(struct module *mod, struct load_info *i
 				mod->name);
 		add_taint_module(mod, TAINT_TEST, LOCKDEP_STILL_OK);
 	}
-#ifdef CONFIG_MODULE_SIG
+#ifdef CONFIG_MODULE_SIG_POLICY
 	mod->sig_ok = info->sig_ok;
 	if (!mod->sig_ok) {
 		pr_notice_once("%s: module verification failed: signature "
@@ -3808,3 +3808,27 @@ static int module_debugfs_init(void)
 }
 module_init(module_debugfs_init);
 #endif
+
+#ifdef CONFIG_MODULE_SIG_POLICY
+
+#undef MODULE_PARAM_PREFIX
+#define MODULE_PARAM_PREFIX "module."
+
+static bool sig_enforce = IS_ENABLED(CONFIG_MODULE_SIG_FORCE);
+module_param(sig_enforce, bool_enable_only, 0644);
+
+/*
+ * Export sig_enforce kernel cmdline parameter to allow other subsystems rely
+ * on that instead of directly to CONFIG_MODULE_SIG_FORCE config.
+ */
+bool is_module_sig_enforced(void)
+{
+	return sig_enforce;
+}
+EXPORT_SYMBOL(is_module_sig_enforced);
+
+void set_module_sig_enforced(void)
+{
+	sig_enforce = true;
+}
+#endif
diff --git a/kernel/module/signing.c b/kernel/module/signing.c
index a2ff4242e623d5d4e87d2f3d139d8620fb937579..e51920605da14771601327ea596dad2e12400518 100644
--- a/kernel/module/signing.c
+++ b/kernel/module/signing.c
@@ -16,27 +16,6 @@
 #include <uapi/linux/module.h>
 #include "internal.h"
 
-#undef MODULE_PARAM_PREFIX
-#define MODULE_PARAM_PREFIX "module."
-
-static bool sig_enforce = IS_ENABLED(CONFIG_MODULE_SIG_FORCE);
-module_param(sig_enforce, bool_enable_only, 0644);
-
-/*
- * Export sig_enforce kernel cmdline parameter to allow other subsystems rely
- * on that instead of directly to CONFIG_MODULE_SIG_FORCE config.
- */
-bool is_module_sig_enforced(void)
-{
-	return sig_enforce;
-}
-EXPORT_SYMBOL(is_module_sig_enforced);
-
-void set_module_sig_enforced(void)
-{
-	sig_enforce = true;
-}
-
 /*
  * Verify the signature on a module.
  */

-- 
2.49.0

[PATCH v3 6/9] module: Move integrity checks into dedicated function

[Thomas Weißschuh]

With the addition of hash-based integrity checking, the configuration
matrix is easier to represent in a dedicated function and with explicit
usage of IS_ENABLED().

Drop the now unnecessary stub for module_sig_check().

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
 kernel/module/internal.h |  7 -------
 kernel/module/main.c     | 18 ++++++++++++++----
 2 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/kernel/module/internal.h b/kernel/module/internal.h
index 626cf8668a7eb9202fce13d631f39429a4fe0ace..42fbc53c6af66a1b531fcad08997742d838eb481 100644
--- a/kernel/module/internal.h
+++ b/kernel/module/internal.h
@@ -325,14 +325,7 @@ int module_enable_text_rox(const struct module *mod);
 int module_enforce_rwx_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
 				char *secstrings, struct module *mod);
 
-#ifdef CONFIG_MODULE_SIG
 int module_sig_check(struct load_info *info, int flags);
-#else /* !CONFIG_MODULE_SIG */
-static inline int module_sig_check(struct load_info *info, int flags)
-{
-	return 0;
-}
-#endif /* !CONFIG_MODULE_SIG */
 
 #ifdef CONFIG_DEBUG_KMEMLEAK
 void kmemleak_load_module(const struct module *mod, const struct load_info *info);
diff --git a/kernel/module/main.c b/kernel/module/main.c
index 83c66205556fdde92152c131f1f58229c4f7f734..0c88d443a3bc894b18a7aa230cadf396e585c415 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -3247,6 +3247,16 @@ static int early_mod_check(struct load_info *info, int flags)
 	return err;
 }
 
+static int module_integrity_check(struct load_info *info, int flags)
+{
+	int err = 0;
+
+	if (IS_ENABLED(CONFIG_MODULE_SIG))
+		err = module_sig_check(info, flags);
+
+	return err;
+}
+
 /*
  * Allocate and load the module: note that size of section 0 is always
  * zero, and we rely on this for optional sections.
@@ -3260,18 +3270,18 @@ static int load_module(struct load_info *info, const char __user *uargs,
 	char *after_dashes;
 
 	/*
-	 * Do the signature check (if any) first. All that
-	 * the signature check needs is info->len, it does
+	 * Do the integrity checks (if any) first. All that
+	 * they need is info->len, it does
 	 * not need any of the section info. That can be
 	 * set up later. This will minimize the chances
 	 * of a corrupt module causing problems before
-	 * we even get to the signature check.
+	 * we even get to the integrity check.
 	 *
 	 * The check will also adjust info->len by stripping
 	 * off the sig length at the end of the module, making
 	 * checks against info->len more correct.
 	 */
-	err = module_sig_check(info, flags);
+	err = module_integrity_check(info, flags);
 	if (err)
 		goto free_copy;
 

-- 
2.49.0

[PATCH v3 7/9] module: Move lockdown check into generic module loader

[Thomas Weißschuh]

The lockdown check buried in module_sig_check() will not compose well
with the introduction of hash-based module validation.
Move it into module_integrity_check() which will work better.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
 kernel/module/main.c    | 6 +++++-
 kernel/module/signing.c | 3 +--
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/kernel/module/main.c b/kernel/module/main.c
index 0c88d443a3bc894b18a7aa230cadf396e585c415..1c353ece05fd1d2d709204e4d5fa44ecb8832bfa 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -3254,7 +3254,11 @@ static int module_integrity_check(struct load_info *info, int flags)
 	if (IS_ENABLED(CONFIG_MODULE_SIG))
 		err = module_sig_check(info, flags);
 
-	return err;
+	if (err)
+		return err;
+	if (info->sig_ok)
+		return 0;
+	return security_locked_down(LOCKDOWN_MODULE_SIGNATURE);
 }
 
 /*
diff --git a/kernel/module/signing.c b/kernel/module/signing.c
index e51920605da14771601327ea596dad2e12400518..029e1ef6f0e369fd48e8c81154b6c697ad7a6249 100644
--- a/kernel/module/signing.c
+++ b/kernel/module/signing.c
@@ -11,7 +11,6 @@
 #include <linux/module_signature.h>
 #include <linux/string.h>
 #include <linux/verification.h>
-#include <linux/security.h>
 #include <crypto/public_key.h>
 #include <uapi/linux/module.h>
 #include "internal.h"
@@ -100,5 +99,5 @@ int module_sig_check(struct load_info *info, int flags)
 		return -EKEYREJECTED;
 	}
 
-	return security_locked_down(LOCKDOWN_MODULE_SIGNATURE);
+	return 0;
 }

-- 
2.49.0

[PATCH v3 8/9] lockdown: Make the relationship to MODULE_SIG a dependency

[Thomas Weißschuh]

The new hash-based module integrity checking will also be able to
satisfy the requirements of lockdown.
Such an alternative is not representable with "select", so use
"depends on" instead.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
 security/lockdown/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/lockdown/Kconfig b/security/lockdown/Kconfig
index e84ddf48401010bcc0829a32db58e6f12bfdedcb..155959205b8eac2c85897a8c4c8b7ec471156706 100644
--- a/security/lockdown/Kconfig
+++ b/security/lockdown/Kconfig
@@ -1,7 +1,7 @@
 config SECURITY_LOCKDOWN_LSM
 	bool "Basic module for enforcing kernel lockdown"
 	depends on SECURITY
-	select MODULE_SIG if MODULES
+	depends on !MODULES || MODULE_SIG
 	help
 	  Build support for an LSM that enforces a coarse kernel lockdown
 	  behaviour.

-- 
2.49.0

Re: [PATCH v3 8/9] lockdown: Make the relationship to MODULE_SIG a dependency

[Paul Moore]

On Tue, Apr 29, 2025 at 9:04 AM Thomas Weißschuh <linux@weissschuh.net> wrote:
>
> The new hash-based module integrity checking will also be able to
> satisfy the requirements of lockdown.
> Such an alternative is not representable with "select", so use
> "depends on" instead.
>
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
>  security/lockdown/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

I'm hopeful that we will see notice about dedicated Lockdown
maintainers soon, but in the meantime this looks okay to me.

Acked-by: Paul Moore <paul@paul-moore.com>

> diff --git a/security/lockdown/Kconfig b/security/lockdown/Kconfig
> index e84ddf48401010bcc0829a32db58e6f12bfdedcb..155959205b8eac2c85897a8c4c8b7ec471156706 100644
> --- a/security/lockdown/Kconfig
> +++ b/security/lockdown/Kconfig
> @@ -1,7 +1,7 @@
>  config SECURITY_LOCKDOWN_LSM
>         bool "Basic module for enforcing kernel lockdown"
>         depends on SECURITY
> -       select MODULE_SIG if MODULES
> +       depends on !MODULES || MODULE_SIG
>         help
>           Build support for an LSM that enforces a coarse kernel lockdown
>           behaviour.
>
> --
> 2.49.0

-- 
paul-moore.com

[PATCH v3 9/9] module: Introduce hash-based integrity checking

[Thomas Weißschuh]

The current signature-based module integrity checking has some drawbacks
in combination with reproducible builds:
Either the module signing key is generated at build time, which makes
the build unreproducible, or a static key is used, which precludes
rebuilds by third parties and makes the whole build and packaging
process much more complicated.
Introduce a new mechanism to ensure only well-known modules are loaded
by embedding a list of hashes of all modules built as part of the full
kernel build into vmlinux.

Non-builtin modules can be validated as before through signatures.

Normally the .ko module files depend on a fully built vmlinux to be
available for modpost validation and BTF generation.
With CONFIG_MODULE_HASHES, vmlinux now depends on the modules
to embed their hashes.
This introduces a dependency cycle which does not work.
Work around this by building the modules during link-vmlinux.sh,
after vmlinux is complete enough for modpost and BTF but before the
final module hashes are added to vmlinux.

This mechanism increases the size of vmlinux by 32 bytes,
one sha256 digest, per module.
On a general-purpose distro kernel with ~6k modules this means a total
increase of memory usage of ~200KiB.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
 .gitignore                                   |  1 +
 Documentation/kbuild/reproducible-builds.rst |  5 ++-
 Makefile                                     |  8 +++-
 include/asm-generic/vmlinux.lds.h            | 11 ++++++
 include/linux/module_hashes.h                | 17 +++++++++
 kernel/module/Kconfig                        | 17 ++++++++-
 kernel/module/Makefile                       |  1 +
 kernel/module/hashes.c                       | 56 ++++++++++++++++++++++++++++
 kernel/module/internal.h                     |  1 +
 kernel/module/main.c                         |  5 ++-
 scripts/Makefile.modfinal                    |  6 +++
 scripts/Makefile.modinst                     |  4 ++
 scripts/Makefile.vmlinux                     |  5 +++
 scripts/link-vmlinux.sh                      | 25 ++++++++++++-
 scripts/module-hashes.sh                     | 26 +++++++++++++
 security/lockdown/Kconfig                    |  2 +-
 16 files changed, 184 insertions(+), 6 deletions(-)

diff --git a/.gitignore b/.gitignore
index f2f63e47fb88686d5d5ab17d480c9301184134a9..ed55ce77be64a9769da7cc103ef56039648b8759 100644
--- a/.gitignore
+++ b/.gitignore
@@ -29,6 +29,7 @@
 *.gz
 *.i
 *.ko
+*.ko.hash
 *.lex.c
 *.ll
 *.lst
diff --git a/Documentation/kbuild/reproducible-builds.rst b/Documentation/kbuild/reproducible-builds.rst
index a7762486c93fcd3eba08b836bed622a41e829e41..013265e9766c88e04fc775bbbb6d3de90c7346e4 100644
--- a/Documentation/kbuild/reproducible-builds.rst
+++ b/Documentation/kbuild/reproducible-builds.rst
@@ -64,7 +64,10 @@ generate a different temporary key for each build, resulting in the
 modules being unreproducible.  However, including a signing key with
 your source would presumably defeat the purpose of signing modules.
 
-One approach to this is to divide up the build process so that the
+Instead ``CONFIG_MODULE_HASHES`` can be used to embed a static list
+of valid modules to load.
+
+Another approach to this is to divide up the build process so that the
 unreproducible parts can be treated as sources:
 
 1. Generate a persistent signing key.  Add the certificate for the key
diff --git a/Makefile b/Makefile
index 38689a0c36052b4ea6541bff8b36048e9689578a..1d04a584d6993a33f7ceefa1bb52727919bb83d0 100644
--- a/Makefile
+++ b/Makefile
@@ -1551,8 +1551,10 @@ endif
 # is an exception.
 ifdef CONFIG_DEBUG_INFO_BTF_MODULES
 KBUILD_BUILTIN := 1
+ifndef CONFIG_MODULE_HASHES
 modules: vmlinux
 endif
+endif
 
 modules: modules_prepare
 
@@ -1933,7 +1935,11 @@ modules.order: $(build-dir)
 # KBUILD_MODPOST_NOFINAL can be set to skip the final link of modules.
 # This is solely useful to speed up test compiles.
 modules: modpost
-ifneq ($(KBUILD_MODPOST_NOFINAL),1)
+ifdef CONFIG_MODULE_HASHES
+ifeq ($(MODULE_HASHES_MODPOST_FINAL), 1)
+	$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modfinal
+endif
+else ifneq ($(KBUILD_MODPOST_NOFINAL),1)
 	$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modfinal
 endif
 
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 58a635a6d5bdf0c53c267c2a3d21a5ed8678ce73..b45b2950c443a62f6086ed209851421c511e078b 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -490,6 +490,8 @@ defined(CONFIG_AUTOFDO_CLANG) || defined(CONFIG_PROPELLER_CLANG)
 									\
 	PRINTK_INDEX							\
 									\
+	MODULE_HASHES							\
+									\
 	/* Kernel symbol table: Normal symbols */			\
 	__ksymtab         : AT(ADDR(__ksymtab) - LOAD_OFFSET) {		\
 		__start___ksymtab = .;					\
@@ -899,6 +901,15 @@ defined(CONFIG_AUTOFDO_CLANG) || defined(CONFIG_PROPELLER_CLANG)
 #define PRINTK_INDEX
 #endif
 
+#ifdef CONFIG_MODULE_HASHES
+#define MODULE_HASHES							\
+	.module_hashes : AT(ADDR(.module_hashes) - LOAD_OFFSET) {	\
+	BOUNDED_SECTION_BY(.module_hashes, _module_hashes)		\
+	}
+#else
+#define MODULE_HASHES
+#endif
+
 /*
  * Discard .note.GNU-stack, which is emitted as PROGBITS by the compiler.
  * Otherwise, the type of .notes section would become PROGBITS instead of NOTES.
diff --git a/include/linux/module_hashes.h b/include/linux/module_hashes.h
new file mode 100644
index 0000000000000000000000000000000000000000..5f2f0546e3875e6bc73bdd53aebaada7371b7f79
--- /dev/null
+++ b/include/linux/module_hashes.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+#ifndef _LINUX_MODULE_HASHES_H
+#define _LINUX_MODULE_HASHES_H
+
+#include <linux/compiler_attributes.h>
+#include <linux/types.h>
+#include <crypto/sha2.h>
+
+#define __module_hashes_section __section(".module_hashes")
+#define MODULE_HASHES_HASH_SIZE SHA256_DIGEST_SIZE
+
+extern const u8 module_hashes[][MODULE_HASHES_HASH_SIZE];
+
+extern const typeof(module_hashes[0]) __start_module_hashes, __stop_module_hashes;
+
+#endif /* _LINUX_MODULE_HASHES_H */
diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig
index a3146e9378fcd3292a756a2a7ea5241524cbc408..54702f24ace4cbd18ffaa6cf7fdb2936ebe8505d 100644
--- a/kernel/module/Kconfig
+++ b/kernel/module/Kconfig
@@ -267,7 +267,7 @@ config MODULE_SIG
 
 config MODULE_SIG_POLICY
 	def_bool y
-	depends on MODULE_SIG
+	depends on MODULE_SIG || MODULE_HASHES
 
 config MODULE_SIG_FORCE
 	bool "Require modules to be validly signed"
@@ -404,6 +404,21 @@ config MODULE_DECOMPRESS
 
 	  If unsure, say N.
 
+config MODULE_HASHES
+	bool "Module hash validation"
+	depends on $(success,openssl dgst -sha256 -binary /dev/null)
+	select CRYPTO_LIB_SHA256
+	help
+	  Validate modules by their hashes.
+	  Only modules built together with the main kernel image can be
+	  validated that way.
+
+	  This is a reproducible-build compatible alternative to a build-time
+	  generated module keyring, as enabled by
+	  CONFIG_MODULE_SIG_KEY=certs/signing_key.pem.
+
+	  Also see the warning in MODULE_SIG about stripping modules.
+
 config MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS
 	bool "Allow loading of modules with missing namespace imports"
 	help
diff --git a/kernel/module/Makefile b/kernel/module/Makefile
index d9e8759a7b05c2d716ab258ae3b55591f869cd52..b3c0bb7d327806726ab8a23d791513e1a0f92706 100644
--- a/kernel/module/Makefile
+++ b/kernel/module/Makefile
@@ -25,3 +25,4 @@ obj-$(CONFIG_KGDB_KDB) += kdb.o
 obj-$(CONFIG_MODVERSIONS) += version.o
 obj-$(CONFIG_MODULE_UNLOAD_TAINT_TRACKING) += tracking.o
 obj-$(CONFIG_MODULE_STATS) += stats.o
+obj-$(CONFIG_MODULE_HASHES) += hashes.o
diff --git a/kernel/module/hashes.c b/kernel/module/hashes.c
new file mode 100644
index 0000000000000000000000000000000000000000..67481b1bb24eb61d364e802d2ab019a9b7f07348
--- /dev/null
+++ b/kernel/module/hashes.c
@@ -0,0 +1,56 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/* Module hash-based integrity checker
+ *
+ * Copyright (C) 2025 Thomas Weißschuh <linux@weissschuh.net>
+ */
+
+#define pr_fmt(fmt) "module/hash: " fmt
+
+#include <linux/int_log.h>
+#include <linux/module_hashes.h>
+#include <linux/module.h>
+#include <crypto/sha2.h>
+#include "internal.h"
+
+static inline size_t module_hashes_count(void)
+{
+	return (__stop_module_hashes - __start_module_hashes) / MODULE_HASHES_HASH_SIZE;
+}
+
+static __init __maybe_unused int module_hashes_init(void)
+{
+	size_t num_hashes = module_hashes_count();
+	int num_width = num_hashes ? (intlog10(num_hashes) >> 24) + 1 : 0;
+	size_t i;
+
+	pr_debug("Known hashes (%zu):\n", num_hashes);
+
+	for (i = 0; i < num_hashes; i++)
+		pr_debug("%*zu %*phN\n", num_width, i,
+			 (int)sizeof(module_hashes[i]), module_hashes[i]);
+
+	return 0;
+}
+
+#if IS_ENABLED(CONFIG_MODULE_DEBUG)
+early_initcall(module_hashes_init);
+#endif
+
+int module_hash_check(struct load_info *info, int flags)
+{
+	u8 digest[MODULE_HASHES_HASH_SIZE];
+	size_t i;
+
+	sha256((const u8 *)info->hdr, info->len, digest);
+
+	for (i = 0; i < module_hashes_count(); i++) {
+		if (memcmp(module_hashes[i], digest, MODULE_HASHES_HASH_SIZE) == 0) {
+			pr_debug("allow %*phN\n", (int)sizeof(digest), digest);
+			info->sig_ok = true;
+			return 0;
+		}
+	}
+
+	pr_debug("block %*phN\n", (int)sizeof(digest), digest);
+	return -ENOKEY;
+}
diff --git a/kernel/module/internal.h b/kernel/module/internal.h
index 42fbc53c6af66a1b531fcad08997742d838eb481..f0ecf7761760cc01e8ec42cde1b5d491be0ee4e3 100644
--- a/kernel/module/internal.h
+++ b/kernel/module/internal.h
@@ -326,6 +326,7 @@ int module_enforce_rwx_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
 				char *secstrings, struct module *mod);
 
 int module_sig_check(struct load_info *info, int flags);
+int module_hash_check(struct load_info *info, int flags);
 
 #ifdef CONFIG_DEBUG_KMEMLEAK
 void kmemleak_load_module(const struct module *mod, const struct load_info *info);
diff --git a/kernel/module/main.c b/kernel/module/main.c
index 1c353ece05fd1d2d709204e4d5fa44ecb8832bfa..0daf19b494d3748a6156d0cb4c8eccfcff9154da 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -3251,7 +3251,10 @@ static int module_integrity_check(struct load_info *info, int flags)
 {
 	int err = 0;
 
-	if (IS_ENABLED(CONFIG_MODULE_SIG))
+	if (IS_ENABLED(CONFIG_MODULE_HASHES))
+		err = module_hash_check(info, flags);
+
+	if (!info->sig_ok && IS_ENABLED(CONFIG_MODULE_SIG))
 		err = module_sig_check(info, flags);
 
 	if (err)
diff --git a/scripts/Makefile.modfinal b/scripts/Makefile.modfinal
index 527f6b27baff9db94d31c15447de445a05bc0634..cf915acba7ce457f4188415c1d8924922fcc3393 100644
--- a/scripts/Makefile.modfinal
+++ b/scripts/Makefile.modfinal
@@ -43,6 +43,9 @@ quiet_cmd_btf_ko = BTF [M] $@
 		$(RESOLVE_BTFIDS) -b $(objtree)/vmlinux.unstripped $@;		\
 	fi;
 
+quiet_cmd_cksum_ko =
+      cmd_cksum_ko = openssl dgst -sha256 -binary $@ > $@.hash
+
 # Same as newer-prereqs, but allows to exclude specified extra dependencies
 newer_prereqs_except = $(filter-out $(PHONY) $(1),$?)
 
@@ -57,6 +60,9 @@ if_changed_except = $(if $(call newer_prereqs_except,$(2))$(cmd-check),      \
 ifdef CONFIG_DEBUG_INFO_BTF_MODULES
 	+$(if $(newer-prereqs),$(call cmd,btf_ko))
 endif
+ifdef CONFIG_MODULE_HASHES
+	$(call cmd,cksum_ko)
+endif
 
 targets += $(modules:%.o=%.ko) $(modules:%.o=%.mod.o) .module-common.o
 
diff --git a/scripts/Makefile.modinst b/scripts/Makefile.modinst
index 1628198f3e8309845adb48d5dbf66b700f9b6ebb..b2e207bacbac9437955d361cab91acdafaf8295f 100644
--- a/scripts/Makefile.modinst
+++ b/scripts/Makefile.modinst
@@ -79,6 +79,10 @@ quiet_cmd_install = INSTALL $@
 # as the options to the strip command.
 ifdef INSTALL_MOD_STRIP
 
+ifdef CONFIG_MODULE_HASHES
+$(error CONFIG_MODULE_HASHES and INSTALL_MOD_STRIP are mutually exclusive)
+endif
+
 ifeq ($(INSTALL_MOD_STRIP),1)
 strip-option := --strip-debug
 else
diff --git a/scripts/Makefile.vmlinux b/scripts/Makefile.vmlinux
index b0a6cd5b818c9fe19d20f5ddf4908eb14b888ea9..0024a0de1f325daa21170b68a017ebb35b2a630a 100644
--- a/scripts/Makefile.vmlinux
+++ b/scripts/Makefile.vmlinux
@@ -97,6 +97,11 @@ ifdef CONFIG_BUILDTIME_TABLE_SORT
 vmlinux: scripts/sorttable
 endif
 
+ifdef CONFIG_MODULE_HASHES
+vmlinux: $(srctree)/scripts/module-hashes.sh
+vmlinux: modules.order
+endif
+
 # module.builtin.ranges
 # ---------------------------------------------------------------------------
 ifdef CONFIG_BUILTIN_MODULE_RANGES
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index 5f060787ce3fbcbcfdca0c95789d619e2a1c7b72..e60762f2a1655cb0acabd8fd7d5299ad5389796d 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -105,7 +105,7 @@ vmlinux_link()
 	${ld} ${ldflags} -o ${output}					\
 		${wl}--whole-archive ${objs} ${wl}--no-whole-archive	\
 		${wl}--start-group ${libs} ${wl}--end-group		\
-		${kallsymso} ${btf_vmlinux_bin_o} ${arch_vmlinux_o} ${ldlibs}
+		${kallsymso} ${btf_vmlinux_bin_o} ${module_hashes_o} ${arch_vmlinux_o} ${ldlibs}
 }
 
 # generate .BTF typeinfo from DWARF debuginfo
@@ -214,6 +214,7 @@ fi
 
 btf_vmlinux_bin_o=
 kallsymso=
+module_hashes_o=
 strip_debug=
 generate_map=
 
@@ -222,6 +223,17 @@ if is_enabled CONFIG_KALLSYMS; then
 	kallsyms .tmp_vmlinux0.syms .tmp_vmlinux0.kallsyms
 fi
 
+if is_enabled CONFIG_MODULE_HASHES; then
+	# At this point the hashes are still wrong.
+	# This step reserves the exact amount of space for the objcopy step
+	# after BTF generation.
+	${srctree}/scripts/module-hashes.sh prealloc > .tmp_module_hashes.c
+	module_hashes_o=.tmp_module_hashes.o
+	info CC ${module_hashes_o}
+	${CC} ${NOSTDINC_FLAGS} ${LINUXINCLUDE} ${KBUILD_CPPFLAGS} ${KBUILD_CFLAGS} \
+		${KBUILD_CFLAGS_KERNEL} -c -o "${module_hashes_o}" ".tmp_module_hashes.c"
+fi
+
 if is_enabled CONFIG_KALLSYMS || is_enabled CONFIG_DEBUG_INFO_BTF; then
 
 	# The kallsyms linking does not need debug symbols, but the BTF does.
@@ -310,6 +322,17 @@ if is_enabled CONFIG_BUILDTIME_TABLE_SORT; then
 	fi
 fi
 
+if is_enabled CONFIG_MODULE_HASHES; then
+	info MAKE modules
+	${MAKE} -f Makefile MODULE_HASHES_MODPOST_FINAL=1 modules
+	${srctree}/scripts/module-hashes.sh > .tmp_module_hashes.c
+	info CC ${module_hashes_o}
+	${CC} ${NOSTDINC_FLAGS} ${LINUXINCLUDE} ${KBUILD_CPPFLAGS} ${KBUILD_CFLAGS} \
+		${KBUILD_CFLAGS_KERNEL} -fno-lto -c -o "${module_hashes_o}" ".tmp_module_hashes.c"
+	${OBJCOPY} --dump-section .module_hashes=.tmp_module_hashes.bin ${module_hashes_o}
+	${OBJCOPY} --update-section .module_hashes=.tmp_module_hashes.bin ${VMLINUX}
+fi
+
 # step a (see comment above)
 if is_enabled CONFIG_KALLSYMS; then
 	if ! cmp -s System.map "${kallsyms_sysmap}"; then
diff --git a/scripts/module-hashes.sh b/scripts/module-hashes.sh
new file mode 100755
index 0000000000000000000000000000000000000000..120ce924105c51cdd7a704cbec7e5fa356f9ce1a
--- /dev/null
+++ b/scripts/module-hashes.sh
@@ -0,0 +1,26 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0-or-later
+
+set -e
+set -u
+set -o pipefail
+
+prealloc="${1:-}"
+
+echo "#include <linux/module_hashes.h>"
+echo
+echo "const u8 module_hashes[][MODULE_HASHES_HASH_SIZE] __module_hashes_section = {"
+
+for mod in $(< modules.order); do
+	mod="${mod/%.o/.ko}"
+	if [ "$prealloc" = "prealloc" ]; then
+		modhash=""
+	else
+		modhash="$(cat "$mod".hash | hexdump -v -e '"0x" 1/1 "%02x, "')"
+	fi
+	echo -e "\t/* $mod */"
+	echo -e "\t{ $modhash},"
+	echo
+done
+
+echo "};"
diff --git a/security/lockdown/Kconfig b/security/lockdown/Kconfig
index 155959205b8eac2c85897a8c4c8b7ec471156706..60b240e3ef1f9609e3f3241befc0bbc7e4a3db74 100644
--- a/security/lockdown/Kconfig
+++ b/security/lockdown/Kconfig
@@ -1,7 +1,7 @@
 config SECURITY_LOCKDOWN_LSM
 	bool "Basic module for enforcing kernel lockdown"
 	depends on SECURITY
-	depends on !MODULES || MODULE_SIG
+	depends on !MODULES || MODULE_SIG || MODULE_HASHES
 	help
 	  Build support for an LSM that enforces a coarse kernel lockdown
 	  behaviour.

-- 
2.49.0

Re: [PATCH v3 0/9] module: Introduce hash-based integrity checking

[James Bottomley]

On Tue, 2025-04-29 at 15:04 +0200, Thomas Weißschuh wrote:
> The current signature-based module integrity checking has some
> drawbacks in combination with reproducible builds:
> Either the module signing key is generated at build time, which makes
> the build unreproducible,

I don't believe it does: as long as you know what the key was, which
you can get from the kernel keyring, you can exactly reproduce the core
build (it's a public key after all and really equivalent to built in
configuration).  Is the fact that you have to boot the kernel to get
the key the problem?  In which case we could insist it be shipped in
the kernel packaging.

>  or a static key is used, which precludes rebuilds by third parties
> and makes the whole build and packaging process much more
> complicated. 

No, it's the same as above ... as long as you have the public key you
can reproduce the core build with the same end to end hash.

However, is there also a corresponding question of how we verify
reproduceability of kernel builds (and the associated modules ... I
assume for the modules you do strip the appended signature)?  I assume
you're going by the secure boot hash (authenticode hash of the efi stub
and the compressed payload which includes the key).  However, if we had
the vmlinux.o we could do a much more nuanced hash to verify the build,
say by placing the keyring data in a section that isn't hashed.

Regards,

James

Re: [PATCH v3 0/9] module: Introduce hash-based integrity checking

[Thomas Weißschuh]

Hi James,

On 2025-04-29 10:05:04-0400, James Bottomley wrote:
> On Tue, 2025-04-29 at 15:04 +0200, Thomas Weißschuh wrote:
> > The current signature-based module integrity checking has some
> > drawbacks in combination with reproducible builds:
> > Either the module signing key is generated at build time, which makes
> > the build unreproducible,
> 
> I don't believe it does: as long as you know what the key was, which
> you can get from the kernel keyring, you can exactly reproduce the core
> build (it's a public key after all and really equivalent to built in
> configuration).  Is the fact that you have to boot the kernel to get
> the key the problem?  In which case we could insist it be shipped in
> the kernel packaging.

See below.

> >  or a static key is used, which precludes rebuilds by third parties
> > and makes the whole build and packaging process much more
> > complicated. 
> 
> No, it's the same as above ... as long as you have the public key you
> can reproduce the core build with the same end to end hash.

While the scheme you propose does allow verification of rebuildability,
it does not satisfy the requirements for a reproducible build as
understood by the general reproducible builds community:

	When is a build reproducible?

	A build is reproducible if given the same source code, build environment
	and build instructions, any party can recreate bit-by-bit identical
	copies of all specified artifacts.

	The relevant attributes of the build environment, the build instructions
	and the source code as well as the expected reproducible artifacts are
	defined by the authors or distributors. The artifacts of a build are the
	parts of the build results that are the desired primary output.

https://reproducible-builds.org/docs/definition/

Specifically the output of a previous build (the public key, module
signatures) is not available during the rebuild or verification.

> However, is there also a corresponding question of how we verify
> reproduceability of kernel builds (and the associated modules ... I
> assume for the modules you do strip the appended signature)?

Currently distros either don't enforce the reproducibility of the
kernel package at all or disable MODULE_SIG.
With the proposed scheme there would be no signatures on builtin modules.

> I assume
> you're going by the secure boot hash (authenticode hash of the efi stub
> and the compressed payload which includes the key).  However, if we had
> the vmlinux.o we could do a much more nuanced hash to verify the build,
> say by placing the keyring data in a section that isn't hashed.

The currently existing tooling does not have any nuance in its
verifications. It just compares bit-by-bit.
I think this is intentional as any bespoke per-package logic would
introduce possible failure modes and stand in the way of implementing
multiple completely independent verification toolsets.
While bespoke tools like diffoscope exist, these are only for
development and debugging. Not not for the reproducibiliy check itself.

How to handle secure-boot with distro keys is not yet clearly defined.
I see two possibilities, which should be possible with the proposed
scheme, both starting with the build of an unsigned kernel package.
Then a signature would be computed on private infrastructure and either
* shipped in a standalone package, to be combined with the kernel when
  that is installed to the ESP/flash etc.
* used as input of a signed kernel package where it is combined with the
  unsigned kernel image.


Thomas

Re: [PATCH v3 0/9] module: Introduce hash-based integrity checking

[James Bottomley]

On Fri, 2025-05-02 at 08:53 +0200, Thomas Weißschuh wrote:
> Hi James,
> 
> On 2025-04-29 10:05:04-0400, James Bottomley wrote:
> > On Tue, 2025-04-29 at 15:04 +0200, Thomas Weißschuh wrote:
> > > The current signature-based module integrity checking has some
> > > drawbacks in combination with reproducible builds:
> > > Either the module signing key is generated at build time, which
> > > makes the build unreproducible,
> > 
> > I don't believe it does: as long as you know what the key was,
> > which you can get from the kernel keyring, you can exactly
> > reproduce the core build (it's a public key after all and really
> > equivalent to built in configuration).  Is the fact that you have
> > to boot the kernel to get the key the problem?  In which case we
> > could insist it be shipped in the kernel packaging.
> 
> See below.
> 
> > >  or a static key is used, which precludes rebuilds by third
> > > parties and makes the whole build and packaging process much more
> > > complicated. 
> > 
> > No, it's the same as above ... as long as you have the public key
> > you can reproduce the core build with the same end to end hash.
> 
> While the scheme you propose does allow verification of
> rebuildability, it does not satisfy the requirements for a
> reproducible build as understood by the general reproducible builds
> community:
> 
> 	When is a build reproducible?
> 
> 	A build is reproducible if given the same source code, build
> environment
> 	and build instructions, any party can recreate bit-by-bit
> identical
> 	copies of all specified artifacts.
> 
> 	The relevant attributes of the build environment, the build
> instructions
> 	and the source code as well as the expected reproducible
> artifacts are
> 	defined by the authors or distributors. The artifacts of a
> build are the
> 	parts of the build results that are the desired primary
> output.
> 
> https://reproducible-builds.org/docs/definition/

That's a doctor doctor problem, and also if we adopted your
interpretation would mean that most kernel packages can never be
reproducible.  The clue is even in the "any party can recreate bit-by-
bit identical copies of all specified artifacts".

Under a your interpretation of the above, any signed binary isn't
"reproducible" even if the underlying build was, which means any secure
boot kernel would never be reproducible because it also has to be a
signed binary.  The solution is simple: can you strip the signature and
reproduce the build?  If yes, then the build is reproducible and even
fits with the "any party can recreate ..." above.   This is the
interpretation pretty much everyone else has been using.  It's why
people like Intel with source only availability and Intel build only
signing tout reproduceability: they only issue signed confidential VM
firmware, but you can technically reproduce the build of the firmware
minus the signature but you can never sign it.

> Specifically the output of any party can recreate bit-by-bit
> identical copies of all specified artifacta previous build (the
> public key, module signatures) is not available during the rebuild or
> verification.

You just strip the signatures before verifying reproducibility.

> > However, is there also a corresponding question of how we verify
> > reproduceability of kernel builds (and the associated modules ... I
> > assume for the modules you do strip the appended signature)?
> 
> Currently distros either don't enforce the reproducibility of the
> kernel package at all or disable MODULE_SIG.
> With the proposed scheme there would be no signatures on builtin
> modules.

If you take off the appended signature off the module, you can verify
reproduceability.

> > I assume you're going by the secure boot hash (authenticode hash of
> > the efi stub and the compressed payload which includes the key). 
> > However, if we had the vmlinux.o we could do a much more nuanced
> > hash to verify the build, say by placing the keyring data in a
> > section that isn't hashed.
> 
> The currently existing tooling does not have any nuance in its
> verifications. It just compares bit-by-bit.

So I think fixing that might be what you want.  All current secure
build processes (hermetic builds, SLSA and the like) are requiring
output provenance (i.e. signed artifacts).  If you try to stand like
Canute against this tide saying "no signed builds", you're simply
opposing progress for the sake of it, particularly when stripping the
signatures for comparison is easy.

> I think this is intentional as any bespoke per-package logic would
> introduce possible failure modes and stand in the way of implementing
> multiple completely independent verification toolsets.
> While bespoke tools like diffoscope exist, these are only for
> development and debugging. Not not for the reproducibiliy check
> itself.

So you think stripping signatures is failure prone?  If that were the
case then so would be verifying signatures upon which our whole secure
boot and signed module loading is based.


> How to handle secure-boot with distro keys is not yet clearly
> defined. I see two possibilities, which should be possible with the
> proposed scheme, both starting with the build of an unsigned kernel
> package. Then a signature would be computed on private infrastructure
> and either
> * shipped in a standalone package, to be combined with the kernel
> when that is installed to the ESP/flash etc.
> * used as input of a signed kernel package where it is combined with
> the unsigned kernel image.

Or you simply ship tools to remove the signature;

sbattach --remove <signed efi variable>

already does this for you ...

Regards,

James

Re: [PATCH v3 0/9] module: Introduce hash-based integrity checking

[kpcyrd]

On 5/2/25 3:30 PM, James Bottomley wrote:
> Under a your interpretation of the above, any signed binary isn't
> "reproducible" even if the underlying build was, which means any secure
> boot kernel would never be reproducible because it also has to be a
> signed binary.  The solution is simple: can you strip the signature and
> reproduce the build?  If yes, then the build is reproducible and even
> fits with the "any party can recreate ..." above.   This is the
> interpretation pretty much everyone else has been using.  It's why
> people like Intel with source only availability and Intel build only
> signing tout reproduceability: they only issue signed confidential VM
> firmware, but you can technically reproduce the build of the firmware
> minus the signature but you can never sign it.

The secure-boot signature is easier to deal with, I also think there'd 
be one package that contains just the unsigned kernel+modules (with the 
modules being pinned by a cryptographic hashset), and a second one that 
takes the kernel secure-boot signature as a source-code input, that is 
calculated after the first package was successfully built.

Arch Linux has also considered patching the module-signing-script into 
some kind of oracle that doesn't use any private key and instead selects 
the right pre-computed signature for the given content, but:

- that would be terribly annoying to maintain/operate
- any reproducible builds regression would make the build fail, because 
the kernel wouldn't be bootable

> You just strip the signatures before verifying reproducibility.
> 
[...]
> 
> If you take off the appended signature off the module, you can verify
> reproduceability.
> 
[...]
> 
> So you think stripping signatures is failure prone?  If that were the
> case then so would be verifying signatures upon which our whole secure
> boot and signed module loading is based.
> 
[...]
> 
> Or you simply ship tools to remove the signature;
> 
> sbattach --remove <signed efi variable>
> 
> already does this for you ...

It reads like you assume somebody sits down and explicitly looks at the 
linux package manually, but the reproducible builds tooling considers 
the package content to be fully opaque and doesn't have any 
special-casing of any package:

https://github.com/archlinux/archlinux-repro
https://salsa.debian.org/debian/devscripts/-/blob/main/scripts/debrebuild.pl?ref_type=heads

I'd rather not deal with the consequences of weakening the comparison 
and possibly introducing exploitable loop-holes in any of the layers we 
wouldn't be able to bit-for-bit compare anymore (like e.g. tar).

It would also break the concept of `f(source) -> binary`, "you can 
deterministically derive the binary packages from the documented build 
inputs", and instead you'd always need to fuzzy-match against what 
somebody else built.

cheers,
kpcyrd

Re: [PATCH v3 0/9] module: Introduce hash-based integrity checking

[James Bottomley]

On Sat, 2025-05-03 at 01:43 +0200, kpcyrd wrote:
> On 5/2/25 3:30 PM, James Bottomley wrote:
[...]
> > Or you simply ship tools to remove the signature;
> > 
> > sbattach --remove <signed efi variable>
> > 
> > already does this for you ...
> 
> It reads like you assume somebody sits down and explicitly looks at
> the linux package manually, but the reproducible builds tooling
> considers the package content to be fully opaque and doesn't have any
> special-casing of any package:
> 
> https://github.com/archlinux/archlinux-repro
> https://salsa.debian.org/debian/devscripts/-/blob/main/scripts/debrebuild.pl?ref_type=heads

How something is packaged for consumers and what the outputs of a build
are are two entirely different things.  But if you control packaging,
you could actually strip the signatures and place them in an unchecked
section as long as you make sure to combine them on installation.

> I'd rather not deal with the consequences of weakening the comparison
> and possibly introducing exploitable loop-holes in any of the layers
> we wouldn't be able to bit-for-bit compare anymore (like e.g. tar).

To repeat the point: what everyone would like to do to make life easy
is a bit different from what has to be done in the modern era of  build
provenance requirements.

> It would also break the concept of `f(source) -> binary`, "you can 
> deterministically derive the binary packages from the documented
> build inputs", and instead you'd always need to fuzzy-match against
> what somebody else built.

I think you'll find

f -> strip signature ° build

Works in the above equation.  The point being it's deterministic, not
fuzzy.

Regards,

James

Re: [PATCH v3 0/9] module: Introduce hash-based integrity checking

[Arnout Engelen]

On Fri, May 2, 2025, at 15:30, James Bottomley wrote:
> On Fri, 2025-05-02 at 08:53 +0200, Thomas Weißschuh wrote:
> > Specifically the output of any party can recreate bit-by-bit
> > identical copies of all specified artifacta previous build (the
> > public key, module signatures) is not available during the rebuild or
> > verification.
> 
> You just strip the signatures before verifying reproducibility.

If the goal is: "verify the Linux Kernel is reproducible", that could work.
It gets increasingly cumbersome when you're trying to check the reproducibility
of some larger artifact that embeds the Linux kernel (and lots of other stuff),
like an ISO or disk image, though: you'd have to unpack/mount it, check all its
contents individually (perhaps recursively), and strip signatures in 'just the
right places'.

Writing such tooling is a chore, but of course feasible: diffoscope already
comes a long way (though checking large images may take some resources). The
problem is trusting such tooling: instead of 'simply' checking the images are
identical, suddenly I now have to convince myself there's no shenanigans
possible in the disk image interpretation and other check tooling, which gets
nontrivial fast.

> All current secure
> build processes (hermetic builds, SLSA and the like) are requiring
> output provenance (i.e. signed artifacts).  If you try to stand like
> Canute against this tide saying "no signed builds", you're simply
> opposing progress for the sake of it

I don't think anyone is saying 'no signed builds', but we'd enjoy being able to
keep the signatures as detached metadata instead of having to embed them into
the 'actual' artifacts.


Kind regards,

Arnout

Re: [PATCH v3 0/9] module: Introduce hash-based integrity checking

[James Bottomley]

On Sat, 2025-05-03 at 10:19 +0200, Arnout Engelen wrote:
> On Fri, May 2, 2025, at 15:30, James Bottomley wrote:
> > On Fri, 2025-05-02 at 08:53 +0200, Thomas Weißschuh wrote:
> > > Specifically the output of any party can recreate bit-by-bit
> > > identical copies of all specified artifacta previous build (the
> > > public key, module signatures) is not available during the
> > > rebuild or verification.
> > 
> > You just strip the signatures before verifying reproducibility.
> 
> If the goal is: "verify the Linux Kernel is reproducible", that could
> work. It gets increasingly cumbersome when you're trying to check the
> reproducibility of some larger artifact that embeds the Linux kernel
> (and lots of other stuff), like an ISO or disk image, though: you'd
> have to unpack/mount it, check all its contents individually (perhaps
> recursively), and strip signatures in 'just the right places'.

Most GPL/LGPL software requires a build recipe anyway.  Realistically,
you're just proving you can exercise that in reverse.

> Writing such tooling is a chore, but of course feasible: diffoscope
> already comes a long way (though checking large images may take some
> resources). The problem is trusting such tooling: instead of 'simply'
> checking the images are identical, suddenly I now have to convince
> myself there's no shenanigans possible in the disk image
> interpretation and other check tooling, which gets nontrivial fast.

I'll repeat the key point again: all modern hermetic build systems come
with provenance which is usually a signature.  Developing the tooling
is already a requirement.

Plus, you've got to remember that a signature is a cryptographic
function of the hash over the build minus the signature.  You can't
verify a signature unless you know how to get the build minus the
signature.  So the process is required to be deterministic.

> > All current secure build processes (hermetic builds, SLSA and the
> > like) are requiring output provenance (i.e. signed artifacts).  If
> > you try to stand like Canute against this tide saying "no signed
> > builds", you're simply opposing progress for the sake of it
> 
> I don't think anyone is saying 'no signed builds', but we'd enjoy
> being able to keep the signatures as detached metadata instead of
> having to embed them into the 'actual' artifacts.

We had this debate about 15 years ago when Debian first started
reproducible builds for the kernel.  Their initial approach was
detached module signatures.  This was the original patch set:

https://lore.kernel.org/linux-modules/20160405001611.GJ21187@decadent.org.uk/

And this is the reason why Debian abandoned it:

https://lists.debian.org/debian-kernel/2016/05/msg00384.html

The specific problem is why detached signatures are almost always a
problem: after a period of time, particularly if the process for
creating updated artifacts gets repeated often matching the output to
the right signature becomes increasingly error prone.

Debian was, however, kind enough to attach what they currently do to
get reproducible builds to the kernel documentation:

https://docs.kernel.org/kbuild/reproducible-builds.html

Although they went for deterministic signing, I will note that it is
perfectly possible to follow their receipe with an ephemeral
certificate as well.

However, if you want to detach the module signatures for packaging, so
the modules can go in a reproducible section and the signatures
elsewhere, then I think we could accommodate that (the output of the
build is actually unsigned modules, they just get signed on install).

Regards,

James

Re: [PATCH v3 0/9] module: Introduce hash-based integrity checking

[Arnout Engelen]

On Tue, May 6, 2025, at 15:24, James Bottomley wrote:
> I'll repeat the key point again: all modern hermetic build systems come
> with provenance which is usually a signature.

I'm not sure the 'hermetic build' parallel is so applicable here: typically a
hermetic build will produce an artifact and a signature, and when you embed
that result in a larger aggregate, you only embed the artifact (not the
signature) and sign the aggregate. With module signatures, the module *and*
their signatures are embedded in the aggregate (e.g. ISO, disk image), which is
where (at least in my case) the friction comes from.

> Plus, you've got to remember that a signature is a cryptographic
> function of the hash over the build minus the signature.  You can't
> verify a signature unless you know how to get the build minus the
> signature.  So the process is required to be deterministic.

Right: there is no friction validating the module signatures, that is fine.
There is friction validating the aggregate artifact (e.g. ISO, disk image),
though, because of those signatures embedded into it.

As you mentioned earlier, of course this is *possible* to do (for example by
adding the signatures as inputs to the second 'independent' build or by
creating a hard-to-validate 'check recipe' running the build in reverse).
Still, checking modules at run time by hash instead of by signature would be a
much simpler option for such scenario's.

> > > All current secure build processes (hermetic builds, SLSA and the
> > > like) are requiring output provenance (i.e. signed artifacts).  If
> > > you try to stand like Canute against this tide saying "no signed
> > > builds", you're simply opposing progress for the sake of it
> > 
> > I don't think anyone is saying 'no signed builds', but we'd enjoy
> > being able to keep the signatures as detached metadata instead of
> > having to embed them into the 'actual' artifacts.
> 
> We had this debate about 15 years ago when Debian first started
> reproducible builds for the kernel.  Their initial approach was
> detached module signatures.  This was the original patch set:
> 
> https://lore.kernel.org/linux-modules/20160405001611.GJ21187@decadent.org.uk/
> 
> And this is the reason why Debian abandoned it:
> 
> https://lists.debian.org/debian-kernel/2016/05/msg00384.html

That is interesting history, thanks for digging that up. Of the 2 problems Ben
mentions running into there, '1' does not seem universal (I think this feature
is indeed mainly interesting for systems where you don't _want_ anyone to be
able to load locally-built modules), and '2' is a problem that detached
signatures have but module hashes don't have.

> The specific problem is why detached signatures are almost always a
> problem: after a period of time, particularly if the process for
> creating updated artifacts gets repeated often matching the output to
> the right signature becomes increasingly error prone.

I haven't experienced that issue with the module hashes yet.

> Debian was, however, kind enough to attach what they currently do to
> get reproducible builds to the kernel documentation:
> 
> https://docs.kernel.org/kbuild/reproducible-builds.html

Cool, I was aware of that page but didn't know it was initially contributed by
Debian.

> However, if you want to detach the module signatures for packaging, so
> the modules can go in a reproducible section and the signatures
> elsewhere, then I think we could accommodate that (the output of the
> build is actually unsigned modules, they just get signed on install).

At least I don't really come to this from the packaging perspective, but from
the "building an independently verifiable ISO/disk image" perspective.
Separating the modules and the signatures into separate packages doesn't help
me there, since they'd still both need to be present on the image.


Kind regards,

-- 
Arnout Engelen
Engelen Open Source
https://engelen.eu

Re: [PATCH v3 0/9] module: Introduce hash-based integrity checking

[James Bottomley]

On Wed, 2025-05-07 at 09:47 +0200, Arnout Engelen wrote:
> On Tue, May 6, 2025, at 15:24, James Bottomley wrote:
> > I'll repeat the key point again: all modern hermetic build systems
> > come with provenance which is usually a signature.
> 
> I'm not sure the 'hermetic build' parallel is so applicable here:
> typically a hermetic build will produce an artifact and a signature,
> and when you embed that result in a larger aggregate, you only embed
> the artifact (not the signature) and sign the aggregate.

That depends whether you want to demonstrate the provenance of the
result to someone consuming your aggregate or not; Some people are OK
with the trust my signature approach, others want tracing to point of
origin.

>  With module signatures, the module *and* their signatures are
> embedded in the aggregate (e.g. ISO, disk image), which is
> where (at least in my case) the friction comes from.

For Linux in particular, most people won't be booting any image unless
the binary is secure boot signed, so this problem doesn't go away if
you strip module signatures.

> > Plus, you've got to remember that a signature is a cryptographic
> > function of the hash over the build minus the signature.  You can't
> > verify a signature unless you know how to get the build minus the
> > signature.  So the process is required to be deterministic.
> 
> Right: there is no friction validating the module signatures, that is
> fine. There is friction validating the aggregate artifact (e.g. ISO,
> disk image), though, because of those signatures embedded into it.

I think we understand the problem with signatures (particularly the
ones which add entropy and can thus change every time the same object
is signed).  However, I don't think we can accept that no signatures
can be on the ISO ... we'll have to have at least secure boot
signatures and if there's a way of doing that then there should be a
way of doing other signatures.

> As you mentioned earlier, of course this is *possible* to do (for
> example by adding the signatures as inputs to the second
> 'independent' build or by creating a hard-to-validate 'check recipe'
> running the build in reverse). Still, checking modules at run time by
> hash instead of by signature would be a much simpler option for such
> scenario's.

Well, my objection was merely to the description saying verifying
reproducibility with signatures was not possible (it is).

However, the problem with distros adopting an immutable hash list for
module loading would be DKMS, but I think the distributions that go
that route have all solved the reproducibility issues with signatures
anyway, so perhaps that's not an issue.

> > > > All current secure build processes (hermetic builds, SLSA and
> > > > the like) are requiring output provenance (i.e. signed
> > > > artifacts).  If you try to stand like Canute against this tide
> > > > saying "no signed builds", you're simply opposing progress for
> > > > the sake of it
> > > 
> > > I don't think anyone is saying 'no signed builds', but we'd enjoy
> > > being able to keep the signatures as detached metadata instead of
> > > having to embed them into the 'actual' artifacts.
> > 
> > We had this debate about 15 years ago when Debian first started
> > reproducible builds for the kernel.  Their initial approach was
> > detached module signatures.  This was the original patch set:
> > 
> > https://lore.kernel.org/linux-modules/20160405001611.GJ21187@decadent.org.uk/
> > 
> > And this is the reason why Debian abandoned it:
> > 
> > https://lists.debian.org/debian-kernel/2016/05/msg00384.html
> 
> That is interesting history, thanks for digging that up. Of the 2
> problems Ben mentions running into there, '1' does not seem universal
> (I think this feature is indeed mainly interesting for systems where
> you don't _want_ anyone to be able to load locally-built modules),
> and '2' is a problem that detached signatures have but module hashes
> don't have.

I think Debian ended up going with 2, but since they also provide DKMS
infrastructure, hash module lists won't work for them anyway.

> > The specific problem is why detached signatures are almost always a
> > problem: after a period of time, particularly if the process for
> > creating updated artifacts gets repeated often matching the output
> > to the right signature becomes increasingly error prone.
> 
> I haven't experienced that issue with the module hashes yet.

Heh, I'll repeat this question after you've done umpteen builds of the
same kernel for debugging purposes. The problem that will bite me is
that I often just rebuild a single module and reinsert to try to chase
a bug down.  With this scheme I can't simply reinsert, I'd have to
rebuild the hash list and reboot the entire vmlinux.

> > Debian was, however, kind enough to attach what they currently do
> > to get reproducible builds to the kernel documentation:
> > 
> > https://docs.kernel.org/kbuild/reproducible-builds.html
> 
> Cool, I was aware of that page but didn't know it was initially
> contributed by Debian.
> 
> > However, if you want to detach the module signatures for packaging,
> > so the modules can go in a reproducible section and the signatures
> > elsewhere, then I think we could accommodate that (the output of
> > the build is actually unsigned modules, they just get signed on
> > install).
> 
> At least I don't really come to this from the packaging perspective,
> but from the "building an independently verifiable ISO/disk image"
> perspective. Separating the modules and the signatures into separate
> packages doesn't help me there, since they'd still both need to be
> present on the image.

So how do you cope with secure boot?  I mean if the object is to
produce an ISO that is demonstrably reproducible but otherwise
unusable, we can certainly script a way to excise all the signatures
including the secure boot one.

Regards,

James

Re: [PATCH v3 0/9] module: Introduce hash-based integrity checking

[Fabian Grünbichler]

On May 7, 2025 6:41 pm, James Bottomley wrote:
> On Wed, 2025-05-07 at 09:47 +0200, Arnout Engelen wrote:
>> On Tue, May 6, 2025, at 15:24, James Bottomley wrote:
>> > I'll repeat the key point again: all modern hermetic build systems
>> > come with provenance which is usually a signature.
>> 
>> I'm not sure the 'hermetic build' parallel is so applicable here:
>> typically a hermetic build will produce an artifact and a signature,
>> and when you embed that result in a larger aggregate, you only embed
>> the artifact (not the signature) and sign the aggregate.
> 
> That depends whether you want to demonstrate the provenance of the
> result to someone consuming your aggregate or not; Some people are OK
> with the trust my signature approach, others want tracing to point of
> origin.

Debian (and derivaties) handle it that way - build results are signed
but the aggregate (repository) has its own signature, and only that is
used as trust anchor by apt. source packages have indiviual signatures
by whoever uploaded them, so you can verify that if you (want to)
rebuild.

>>  With module signatures, the module *and* their signatures are
>> embedded in the aggregate (e.g. ISO, disk image), which is
>> where (at least in my case) the friction comes from.
> 
> For Linux in particular, most people won't be booting any image unless
> the binary is secure boot signed, so this problem doesn't go away if
> you strip module signatures.

it is reduced in complexity though, see below.

>> > Plus, you've got to remember that a signature is a cryptographic
>> > function of the hash over the build minus the signature.  You can't
>> > verify a signature unless you know how to get the build minus the
>> > signature.  So the process is required to be deterministic.
>> 
>> Right: there is no friction validating the module signatures, that is
>> fine. There is friction validating the aggregate artifact (e.g. ISO,
>> disk image), though, because of those signatures embedded into it.
> 
> I think we understand the problem with signatures (particularly the
> ones which add entropy and can thus change every time the same object
> is signed).  However, I don't think we can accept that no signatures
> can be on the ISO ... we'll have to have at least secure boot
> signatures and if there's a way of doing that then there should be a
> way of doing other signatures.

secure boot signatures (other than for kernel modules) are added as a
separate step at least in Debian(-based distros). this means that for
every -signed package you have an unsigned counter part that is
(hopefully) reproducible, and the difference is only the signature(s)
(which might be detached or attached, depending on the package).

building such a package boils down to:
- build the unsigned package(s) + a helper package instructing the signing
  machinery which files to sign with which key
- pass the helper package to the signing infrastructure
- signing infrastructure calculates digest and generates signature
  value, and puts that into another source package for the -signed
  variant
- "build" that source package (e.g., [0]), which might mean attaching
  the signature to the corresponding binary artifact, or just storing
  the signature somewhere to be handled later

this way, the part of infrastructure that handles signing (and thus
access to the corresponding secret key material) is decoupled from the
regular build infrastructure and can have a vastly reduced attack
surface. it has the additional side-effect that the actual "build" steps
are each reproducible (modulo bugs affecting that, of course). the
signing step obviously isn't, but that isn't really a problem..

>> As you mentioned earlier, of course this is *possible* to do (for
>> example by adding the signatures as inputs to the second
>> 'independent' build or by creating a hard-to-validate 'check recipe'
>> running the build in reverse). Still, checking modules at run time by
>> hash instead of by signature would be a much simpler option for such
>> scenario's.
> 
> Well, my objection was merely to the description saying verifying
> reproducibility with signatures was not possible (it is).

verifying reproducibility of the *unsigned* kernel package doesn't
require any special hacks or mangling if the modules themselves are not
signed using an ephemeral key. (there are currently still other issues
affecting reproducibility, but that would be the goal!)

> However, the problem with distros adopting an immutable hash list for
> module loading would be DKMS, but I think the distributions that go
> that route have all solved the reproducibility issues with signatures
> anyway, so perhaps that's not an issue.

DKMS usually uses MOK as trust anchor, and that key is not
provided/managed by the distro, all the signing happens on the user
side, DKMS packages just ship the module source code + build scripts.

so this is orthogonal - yes, if you want to support DKMS (or other
out-of-tree modules), those modules cannot be included in an in-tree
hash list and would still need to be signed somehow by a trusted key.

basically, both current solutions have downsides:

- signing modules after the build, similar to the kernel image itself,
  is rather impractical with the number of modules shipped by the usual
  distro packages, and relies on other safeguards/invariants not being
  broken to prevent downgrade attacks
- signing modules during the build using an ephemeral key requires
  stripping the signatures when verifying reproducibility (this
  discussion ;)), but also requires enough entropy and not even
  read-only access to the build environment by a potential attacker,
  since if they can read/leak the ephemeral key, they can later attack
  all systems running this particular kernel build

in practice many distros combine both approaches - ephemeral keys for
modules shipped as part of the kernel build, other trusted keys for
out-of-tree modules like DKMS, proprietary drivers, livepatching, ..

the module hash approach (provided it has an opt-in escape hatch for
trusted out-of-tree modules like DKMS) solves all those downsides, as
far as I can tell. you still need all the safeguards/invariants if you
use signed out-of-tree modules of course, if that is part of your use
case. but e.g. AFAIK for Debian (and us as downstream), the only modules
not built as part of the kernel build are built by DKMS on user systems,
and those are signed by the MOK managed by the user/admin.

>> > > > All current secure build processes (hermetic builds, SLSA and
>> > > > the like) are requiring output provenance (i.e. signed
>> > > > artifacts).  If you try to stand like Canute against this tide
>> > > > saying "no signed builds", you're simply opposing progress for
>> > > > the sake of it
>> > > 
>> > > I don't think anyone is saying 'no signed builds', but we'd enjoy
>> > > being able to keep the signatures as detached metadata instead of
>> > > having to embed them into the 'actual' artifacts.
>> > 
>> > We had this debate about 15 years ago when Debian first started
>> > reproducible builds for the kernel.  Their initial approach was
>> > detached module signatures.  This was the original patch set:
>> > 
>> > https://lore.kernel.org/linux-modules/20160405001611.GJ21187@decadent.org.uk/
>> > 
>> > And this is the reason why Debian abandoned it:
>> > 
>> > https://lists.debian.org/debian-kernel/2016/05/msg00384.html
>> 
>> That is interesting history, thanks for digging that up. Of the 2
>> problems Ben mentions running into there, '1' does not seem universal
>> (I think this feature is indeed mainly interesting for systems where
>> you don't _want_ anyone to be able to load locally-built modules),
>> and '2' is a problem that detached signatures have but module hashes
>> don't have.
> 
> I think Debian ended up going with 2, but since they also provide DKMS
> infrastructure, hash module lists won't work for them anyway.

Debian switched to using an ephemeral key 1.5 years ago for the modules
shipped with the kernel package itself (the dkms package ships MOK
integration to streamline that usecase)[1].

build artifacts in Debian are signed in a way that makes reproducing
them straightforward - the (provenance) signatures are not embedded into
the packages. it's basically just secure boot where Debian generates the
signature and *has* to store it inside a package, and there the actual
build and the signature handling are decoupled to minimize the fallout.

>> > The specific problem is why detached signatures are almost always a
>> > problem: after a period of time, particularly if the process for
>> > creating updated artifacts gets repeated often matching the output
>> > to the right signature becomes increasingly error prone.
>> 
>> I haven't experienced that issue with the module hashes yet.
> 
> Heh, I'll repeat this question after you've done umpteen builds of the
> same kernel for debugging purposes. The problem that will bite me is
> that I often just rebuild a single module and reinsert to try to chase
> a bug down.  With this scheme I can't simply reinsert, I'd have to
> rebuild the hash list and reboot the entire vmlinux.

or you could sign the module with a MOK - supporting that in combination
with the hash list is a requirement for pretty much every distro out
there anyway to support DKMS?

>> > Debian was, however, kind enough to attach what they currently do
>> > to get reproducible builds to the kernel documentation:
>> > 
>> > https://docs.kernel.org/kbuild/reproducible-builds.html
>> 
>> Cool, I was aware of that page but didn't know it was initially
>> contributed by Debian.
>> 
>> > However, if you want to detach the module signatures for packaging,
>> > so the modules can go in a reproducible section and the signatures
>> > elsewhere, then I think we could accommodate that (the output of
>> > the build is actually unsigned modules, they just get signed on
>> > install).
>> 
>> At least I don't really come to this from the packaging perspective,
>> but from the "building an independently verifiable ISO/disk image"
>> perspective. Separating the modules and the signatures into separate
>> packages doesn't help me there, since they'd still both need to be
>> present on the image.
> 
> So how do you cope with secure boot?  I mean if the object is to
> produce an ISO that is demonstrably reproducible but otherwise
> unusable, we can certainly script a way to excise all the signatures
> including the secure boot one.

although I am not the one you directed this question at, I'd still like
to give an answer from my PoV:

by simply treating both the -unsigned and -signed source packages as
separate input for determining reproducibility, you can work around this
issue. the signature is part of the "source" of the latter, and as long
as the unsigned package is reproducible, the signed counterpart is as
well, even if you haven't "reproduced" the signature creation.

this is exactly the reason why ephemeral keys used for signing are
breaking reproducible builds, it's no longer possible to reproduce the
"partially-signed"[2] kernel package in the usual fashion (without
mangling).

0: https://buildd.debian.org/status/fetch.php?pkg=fwupd-amd64-signed&arch=amd64&ver=1%3A1.7%2B1&stamp=1726899394&raw=0
1: https://tracker.debian.org/news/1482751/accepted-linux-663-1exp1-source-into-experimental/
2: i.e., with just the modules signed, but the image itself not

Re: [PATCH v3 0/9] module: Introduce hash-based integrity checking

[Mimi Zohar]

Hi Thomas,

On Tue, 2025-04-29 at 15:04 +0200, Thomas Weißschuh wrote:
> The current signature-based module integrity checking has some drawbacks
> in combination with reproducible builds:
> Either the module signing key is generated at build time, which makes
> the build unreproducible, or a static key is used, which precludes
> rebuilds by third parties and makes the whole build and packaging
> process much more complicated.
> Introduce a new mechanism to ensure only well-known modules are loaded
> by embedding a list of hashes of all modules built as part of the full
> kernel build into vmlinux.

From a very high level, I like the idea of including the kernel module hashes
in the kernel image, which is signed, and falling back to verifying other
kernel modules based on signatures.

Removing the CONFIG_MODULE_SIG and CONFIG_KEXEC_SIG checks in the first two
patches is correct, as previously mentioned.  However without these Kconfigs
being enabled, the IMA arch specific policy defines and enforces signature
verification based on the signatures stored in security.ima.  I doubt this is
what was intended.

Changes would be needed in ima_appraise_measurement().  It's not enough to
test whether the policy permits appended signatures (modsig), but to detect
whether CONFIG_MODULE_SIG is enabled.  In addition, similar support to
try_modsig, needs to be added for CONFIG_MODULE_HASHES.

thanks,

Mimi

> 
> Interest has been proclaimed by NixOS, Arch Linux, Proxmox, SUSE and the
> general reproducible builds community.
> 
> To properly test the reproducibility in combination with CONFIG_INFO_BTF
> another patch or pahole v1.29 is needed:
> "[PATCH bpf-next] kbuild, bpf: Enable reproducible BTF generation" [0]
> 
> Questions for current patch:
> * Naming
> * Can the number of built-in modules be retrieved while building
>   kernel/module/hashes.o? This would remove the need for the
>   preallocation step in link-vmlinux.sh.
> * How should this interaction with IMA?
> 
> Further improvements:
> * Use a LSM/IMA Keyring to store and validate hashes
> * Use MODULE_SIG_HASH for configuration
> * UAPI for discovery?
> * Currently has a permanent memory overhead
> 
> [0]
> https://lore.kernel.org/lkml/20241211-pahole-reproducible-v1-1-22feae19bad9@weissschuh.net/
> 
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
> Changes in v3:
> - Rebase on v6.15-rc1
> - Use openssl to calculate hash
> - Avoid warning if no modules are built
> - Simplify module_integrity_check() a bit
> - Make incompatibility with INSTALL_MOD_STRIP explicit
> - Update docs
> - Add IMA cleanups
> - Link to v2:
> https://lore.kernel.org/r/20250120-module-hashes-v2-0-ba1184e27b7f@weissschuh.net
> 
> Changes in v2:
> - Drop RFC state
> - Mention interested parties in cover letter
> - Expand Kconfig description
> - Add compatibility with CONFIG_MODULE_SIG
> - Parallelize module-hashes.sh
> - Update Documentation/kbuild/reproducible-builds.rst
> - Link to v1:
> https://lore.kernel.org/r/20241225-module-hashes-v1-0-d710ce7a3fd1@weissschuh.net
> 
> ---
> Thomas Weißschuh (9):
>       powerpc/ima: Drop unnecessary check for CONFIG_MODULE_SIG
>       ima: efi: Drop unnecessary check for
> CONFIG_MODULE_SIG/CONFIG_KEXEC_SIG
>       kbuild: add stamp file for vmlinux BTF data
>       kbuild: generate module BTF based on vmlinux.unstripped
>       module: Make module loading policy usable without MODULE_SIG
>       module: Move integrity checks into dedicated function
>       module: Move lockdown check into generic module loader
>       lockdown: Make the relationship to MODULE_SIG a dependency
>       module: Introduce hash-based integrity checking
> 
>  .gitignore                                   |  1 +
>  Documentation/kbuild/reproducible-builds.rst |  5 ++-
>  Makefile                                     |  8 +++-
>  arch/powerpc/kernel/ima_arch.c               |  3 +-
>  include/asm-generic/vmlinux.lds.h            | 11 ++++++
>  include/linux/module.h                       |  8 ++--
>  include/linux/module_hashes.h                | 17 +++++++++
>  kernel/module/Kconfig                        | 21 ++++++++++-
>  kernel/module/Makefile                       |  1 +
>  kernel/module/hashes.c                       | 56
> ++++++++++++++++++++++++++++
>  kernel/module/internal.h                     |  8 +---
>  kernel/module/main.c                         | 51 ++++++++++++++++++++++---
>  kernel/module/signing.c                      | 24 +-----------
>  scripts/Makefile.modfinal                    | 18 ++++++---
>  scripts/Makefile.modinst                     |  4 ++
>  scripts/Makefile.vmlinux                     |  5 +++
>  scripts/link-vmlinux.sh                      | 31 ++++++++++++++-
>  scripts/module-hashes.sh                     | 26 +++++++++++++
>  security/integrity/ima/ima_efi.c             |  6 +--
>  security/lockdown/Kconfig                    |  2 +-
>  20 files changed, 250 insertions(+), 56 deletions(-)
> ---
> base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8
> change-id: 20241225-module-hashes-7a50a7cc2a30
> 
> Best regards,