Re: [PATCH v5 12/14] module: Introduce hash-based integrity checking

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Build corruption due to concurrent Kbuild executions of the `modules` target.
- [High] Standalone module builds and installations are fundamentally broken.
- [Low] Memory leak in the `modules-merkle-tree` host utility.
--

commit 199906bc761e41bbeca38213843237f79baf0aaf
Author: Thomas Weißschuh <linux@weissschuh.net>

module: Introduce hash-based integrity checking

This commit introduces a hash-based integrity checking mechanism to support
reproducible builds. It embeds a Merkle tree root of all builtin modules
into vmlinux, while out-of-tree modules continue to be validated through
signatures.

> diff --git a/scripts/Makefile.modinst b/scripts/Makefile.modinst
> index 9ba45e5b32b18..68708a039a621 100644
> --- a/scripts/Makefile.modinst
> +++ b/scripts/Makefile.modinst
[ ... ]
> @@ -116,6 +122,11 @@ quiet_cmd_sign :=
>        cmd_sign := :
>  endif
>  
> +ifeq ($(KBUILD_EXTMOD)|$(CONFIG_MODULE_HASHES),|y)
> +quiet_cmd_sign = MERKLE [M] $@
> +      cmd_sign = cat $(objtree)/$*.merkle >> $@
> +endif

If modules are built and installed independently of a full vmlinux compilation
using make modules followed by make modules_install, will this cat command
abort with a missing file error? 

The .merkle files appear to only be generated by scripts/modules-merkle-tree
during the vmlinux link stage, which might leave standalone module builds
without the required proof files.

> diff --git a/scripts/Makefile.vmlinux b/scripts/Makefile.vmlinux
> index 6cc661e5292b0..a0332c06bde1d 100644
> --- a/scripts/Makefile.vmlinux
> +++ b/scripts/Makefile.vmlinux
[ ... ]
> @@ -78,6 +78,33 @@ ifdef CONFIG_BUILDTIME_TABLE_SORT
>  vmlinux.unstripped: scripts/sorttable
>  endif
>  
> +ifdef CONFIG_MODULE_HASHES
> +targets += .tmp_module_hashes.c
> +
> +modules.order: vmlinux.unstripped FORCE
> +	$(Q)echo "  MAKE    modules"
> +	$(Q)$(MAKE) -f $(srctree)/Makefile modules

Can this recursive make invocation race with the top-level modules target if
a user runs make -j vmlinux modules? 

Since both targets share the modpost prerequisite, it seems Kbuild could
evaluate both concurrently. This might cause two independent instances of
scripts/Makefile.modfinal to compile and link the exact same .mod.o and
.ko files at the same time, leading to unpredictable file truncations.

> diff --git a/scripts/modules-merkle-tree.c b/scripts/modules-merkle-tree.c
> new file mode 100644
> index 0000000000000..10e3455d5d7af
> --- /dev/null
> +++ b/scripts/modules-merkle-tree.c
[ ... ]
> +	mt = build_merkle(fh_list, num_files);
> +	write_merkle_root(mt, argv[1]);
> +	for (size_t i = 0; i < num_files; i++) {
> +		char *signame;
> +		int fd;
> +
> +		signame = xstrdup_replace_suffix(fh_list[i].name, kmod_suffix, ".merkle");
> +
> +		fd = open(signame, O_WRONLY | O_CREAT | O_TRUNC, 0644);
> +		if (fd < 0)
> +			err(1, "Can't create %s", signame);
> +
> +		build_proof(mt, i, fd);
> +		append_module_signature_magic(fd, lseek(fd, 0, SEEK_CUR));
> +		if (close(fd))
> +			err(1, "Can't write %s", signame);
> +	}

Does this code leak the signame string? The xstrdup_replace_suffix helper
allocates memory that does not appear to be freed before the end of the
loop, which might leave memory stranded for each kernel module processed.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260505-module-hashes-v5-0-e174a5a49fce@weissschuh.net?part=12