From: sashiko-bot@kernel.org
To: "Thomas Weißschuh" <linux@weissschuh.net>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH v5 13/14] kbuild: move handling of module stripping to Makefile.lib
Date: Tue, 05 May 2026 09:35:45 +0000 [thread overview]
Message-ID: <20260505093546.5ED89C2BCB4@smtp.kernel.org> (raw)
In-Reply-To: <20260505-module-hashes-v5-13-e174a5a49fce@weissschuh.net>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Reusing `INSTALL_MOD_STRIP` in the build phase violates the separation of build and install phases, breaking standard user workflows and core kernel packaging scripts.
--
commit 82e978c8789922dfed0ff25bf7970d67d952508d
Author: Thomas Weißschuh <linux@weissschuh.net>
kbuild: move handling of module stripping to Makefile.lib
This commit moves the INSTALL_MOD_STRIP logic to Makefile.lib so that it
can be reused by Makefile.modfinal, allowing CONFIG_MODULE_HASHES in
combination with module stripping.
> To allow CONFIG_MODULE_HASHES in combination with INSTALL_MOD_STRIP,
> this logc will also be used by Makefile.modfinal.
This isn't a bug, but there's a typo (logc) in the commit message.
More importantly, does evaluating INSTALL_MOD_STRIP during the build phase
(Makefile.modfinal) violate the separation of the build and install phases?
INSTALL_MOD_STRIP is traditionally an install-phase variable passed strictly
to make modules_install (e.g., make INSTALL_MOD_STRIP=1 modules_install).
Core kernel packaging scripts heavily rely on passing INSTALL_MOD_STRIP only
during the install phase. For example, scripts/package/builddeb executes:
make -f Makefile INSTALL_MOD_PATH="..." INSTALL_MOD_STRIP=1 modules_install
during debian/rules binary, while the build phase runs without this variable.
Similar logic exists in Arch PKGBUILD and RPM kernel.spec.
If build tools do not export INSTALL_MOD_STRIP during the build phase,
relying on it during Makefile.modfinal will mean the build phase and
install phase have different views of the variable. If a subsequent commit
enforces that the build-time and install-time values of INSTALL_MOD_STRIP
must match, wouldn't this break package build targets like make bindeb-pkg
or make rpm-pkg?
If build-phase module stripping is required to support hashes, should this
be governed by a dedicated build-time Kconfig option, rather than
repurposing an install-time Kbuild environment variable?
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
[ ... ]
> +# Module Strip
> +# ---------------------------------------------------------------------------
> +#
> +# INSTALL_MOD_STRIP, if defined, will cause modules to be stripped after they
> +# are installed. If INSTALL_MOD_STRIP is '1', then the default option
> +# --strip-debug will be used. Otherwise, INSTALL_MOD_STRIP value will be used
> +# as the options to the strip command.
> +ifeq ($(INSTALL_MOD_STRIP),1)
> +mod-strip-option := --strip-debug
> +else
> +mod-strip-option := $(INSTALL_MOD_STRIP)
> +endif
Since this is now in Makefile.lib and evaluated during both build and install,
can this cause inconsistencies if users run a standard workflow like:
make
sudo make INSTALL_MOD_STRIP=1 modules_install
Will the build phase have generated hashes based on unstripped modules,
rendering the hashes invalid when the modules are later stripped during
installation?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260505-module-hashes-v5-0-e174a5a49fce@weissschuh.net?part=13
next prev parent reply other threads:[~2026-05-05 9:35 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-05 9:05 [PATCH v5 00/14] module: Introduce hash-based integrity checking Thomas Weißschuh
2026-05-05 9:05 ` [PATCH v5 01/14] kbuild: generate module BTF based on vmlinux.unstripped Thomas Weißschuh
2026-05-05 9:05 ` [PATCH v5 02/14] lockdown: Make the relationship to MODULE_SIG a dependency Thomas Weißschuh
2026-05-05 9:32 ` sashiko-bot
2026-05-05 12:27 ` Nicolas Bouchinet
2026-05-05 9:05 ` [PATCH v5 03/14] kbuild: rename the strip_relocs command Thomas Weißschuh
2026-05-05 9:05 ` [PATCH v5 04/14] module: Drop pointless debugging message Thomas Weißschuh
2026-05-05 9:05 ` [PATCH v5 05/14] module: Make mod_verify_sig() static Thomas Weißschuh
2026-05-05 9:05 ` [PATCH v5 06/14] module: Switch load_info::len to size_t Thomas Weißschuh
2026-05-26 9:47 ` Petr Pavlu
2026-05-26 11:35 ` Thomas Weißschuh
2026-05-05 9:05 ` [PATCH v5 07/14] module: Make module authentication usable without MODULE_SIG Thomas Weißschuh
2026-05-05 9:40 ` sashiko-bot
2026-05-26 10:53 ` Petr Pavlu
2026-05-26 11:38 ` Thomas Weißschuh
2026-05-26 12:27 ` kpcyrd
2026-05-05 9:05 ` [PATCH v5 08/14] module: Move authentication logic into dedicated new file Thomas Weißschuh
2026-05-26 11:58 ` Petr Pavlu
2026-05-05 9:05 ` [PATCH v5 09/14] module: Move signature type check out of mod_check_sig() Thomas Weißschuh
2026-05-26 13:03 ` Petr Pavlu
2026-05-05 9:05 ` [PATCH v5 10/14] module: Prepare for additional module authentication mechanisms Thomas Weißschuh
2026-05-26 13:14 ` Petr Pavlu
2026-05-05 9:05 ` [PATCH v5 11/14] module: update timestamp of modules.order after modules are built Thomas Weißschuh
2026-05-05 9:41 ` sashiko-bot
2026-05-05 9:05 ` [PATCH v5 12/14] module: Introduce hash-based integrity checking Thomas Weißschuh
2026-05-05 9:49 ` sashiko-bot
2026-05-05 9:05 ` [PATCH v5 13/14] kbuild: move handling of module stripping to Makefile.lib Thomas Weißschuh
2026-05-05 9:35 ` sashiko-bot [this message]
2026-05-05 9:05 ` [PATCH v5 14/14] kbuild: make CONFIG_MODULE_HASHES compatible with module stripping Thomas Weißschuh
2026-05-05 10:04 ` sashiko-bot
2026-05-18 21:55 ` [PATCH v5 00/14] module: Introduce hash-based integrity checking Sami Tolvanen
2026-05-19 18:19 ` Thomas Weißschuh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260505093546.5ED89C2BCB4@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=sashiko@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.