* Re: [PATCH v2] module: print version for external modules in print_modules()
From: Yafang Shao @ 2026-02-26 2:18 UTC (permalink / raw)
To: mcgrof, petr.pavlu, da.gomez, samitolvanen, atomlin; +Cc: linux-modules
In-Reply-To: <20251231094004.37851-1-laoar.shao@gmail.com>
On Wed, Dec 31, 2025 at 5:40 PM Yafang Shao <laoar.shao@gmail.com> wrote:
>
> We maintain a vmcore analysis script on each server that automatically
> parses /var/crash/XXXX/vmcore-dmesg.txt to categorize vmcores. This helps
> us save considerable effort by avoiding analysis of known bugs.
>
> For vmcores triggered by a driver bug, the system calls print_modules() to
> list the loaded modules. However, print_modules() does not output module
> version information. Across a large fleet of servers, there are often many
> different module versions running simultaneously, and we need to know which
> driver version caused a given vmcore.
>
> Currently, the only reliable way to obtain the module version associated
> with a vmcore is to analyze the /var/crash/XXXX/vmcore file itself—an
> operation that is resource-intensive. Therefore, we propose printing the
> driver version directly in the log, which is far more efficient.
>
> The motivation behind this change is that the external NVIDIA driver
> [0] frequently causes kernel panics across our server fleet.
> While we continuously upgrade to newer NVIDIA driver versions,
> upgrading the entire fleet is time-consuming. Therefore, we need to
> identify which driver version is responsible for each panic.
>
> In-tree modules are tied to the specific kernel version already, so
> printing their versions is redundant. However, for external drivers (like
> proprietary networking or GPU stacks), the version is the single most
> critical piece of metadata for triage. Therefore, to avoid bloating the
> information about loaded modules, we only print the version for external
> modules.
>
> - Before this patch
>
> Modules linked in: mlx5_core(O) nvidia(PO) nvme_core
>
> - After this patch
>
> Modules linked in: mlx5_core-5.8-2.0.3(O) nvidia-535.274.02(PO) nvme_core
> ^^^^^^^^^^ ^^^^^^^^^^^
>
> Note: nvme_core is a in-tree module[1], so its version isn't printed.
>
> Link: https://github.com/NVIDIA/open-gpu-kernel-modules/tags [0]
> Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/nvme/host/core.c?h=v6.19-rc3#n5448 [1]
> Suggested-by: Petr Pavlu <petr.pavlu@suse.com>
> Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
> Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
> ---
> kernel/module/main.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> ---
> v1->v2:
> - print it for external module only (Petr, Aaron)
> - add comment for it (Aaron)
>
> diff --git a/kernel/module/main.c b/kernel/module/main.c
> index 710ee30b3bea..16263ce23e92 100644
> --- a/kernel/module/main.c
> +++ b/kernel/module/main.c
> @@ -3901,7 +3901,11 @@ void print_modules(void)
> list_for_each_entry_rcu(mod, &modules, list) {
> if (mod->state == MODULE_STATE_UNFORMED)
> continue;
> - pr_cont(" %s%s", mod->name, module_flags(mod, buf, true));
> + pr_cont(" %s", mod->name);
> + /* Only append version for out-of-tree modules */
> + if (mod->version && test_bit(TAINT_OOT_MODULE, &mod->taints))
> + pr_cont("-%s", mod->version);
> + pr_cont("%s", module_flags(mod, buf, true));
> }
>
> print_unloaded_tainted_modules();
> --
> 2.43.5
>
Just checking in on this patch. It looks like it hasn't been merged
yet. Is it good to go, or does it need something else?
--
Regards
Yafang
^ permalink raw reply
* Re: [PATCH] kernel/trace/ftrace: introduce ftrace module notifier
From: Steven Rostedt @ 2026-02-26 0:27 UTC (permalink / raw)
To: chensong_2000
Cc: mcgrof, petr.pavlu, da.gomez, samitolvanen, atomlin, mhiramat,
mark.rutland, mathieu.desnoyers, linux-modules, linux-kernel,
linux-trace-kernel
In-Reply-To: <20260225054639.21637-1-chensong_2000@189.cn>
On Wed, 25 Feb 2026 13:46:39 +0800
chensong_2000@189.cn wrote:
> From: Song Chen <chensong_2000@189.cn>
>
> Like kprobe, fprobe and btf, this patch attempts to introduce
> a notifier_block for ftrace to decouple its initialization from
> load_module.
>
> Below is the table of ftrace fucntions calls in different
> module state:
>
> MODULE_STATE_UNFORMED ftrace_module_init
> MODULE_STATE_COMING ftrace_module_enable
> MODULE_STATE_LIVE ftrace_free_mem
> MODULE_STATE_GOING ftrace_release_mod
>
> Unlike others, ftrace module notifier must take care of state
> MODULE_STATE_UNFORMED to ensure calling ftrace_module_init
> before complete_formation which changes module's text property.
>
> That pretty much remains same logic with its original design,
> the only thing that changes is blocking_notifier_call_chain
> (MODULE_STATE_GOING) has to be moved from coming_cleanup to
> ddebug_cleanup in function load_module to ensure
> ftrace_release_mod is invoked in case complete_formation fails.
>
> Signed-off-by: Song Chen <chensong_2000@189.cn>
> ---
> kernel/module/main.c | 14 ++++----------
> kernel/trace/ftrace.c | 37 +++++++++++++++++++++++++++++++++++++
> 2 files changed, 41 insertions(+), 10 deletions(-)
>
> diff --git a/kernel/module/main.c b/kernel/module/main.c
> index 710ee30b3bea..5dc0a980e9bd 100644
> --- a/kernel/module/main.c
> +++ b/kernel/module/main.c
> @@ -45,7 +45,6 @@
> #include <linux/license.h>
> #include <asm/sections.h>
> #include <linux/tracepoint.h>
> -#include <linux/ftrace.h>
> #include <linux/livepatch.h>
> #include <linux/async.h>
> #include <linux/percpu.h>
> @@ -836,7 +835,6 @@ SYSCALL_DEFINE2(delete_module, const char __user *, name_user,
> blocking_notifier_call_chain(&module_notify_list,
> MODULE_STATE_GOING, mod);
> klp_module_going(mod);
> - ftrace_release_mod(mod);
Is the above safe? klp uses ftrace. That means klp_module_going() may
need to be called before ftrace_release_mod(). That said, I wonder if
klp_module_going() could be moved into ftrace_release_mod()?
>
> async_synchronize_full();
>
> @@ -3067,8 +3065,6 @@ static noinline int do_init_module(struct module *mod)
> if (!mod->async_probe_requested)
> async_synchronize_full();
>
> - ftrace_free_mem(mod, mod->mem[MOD_INIT_TEXT].base,
> - mod->mem[MOD_INIT_TEXT].base + mod->mem[MOD_INIT_TEXT].size);
Have you tested the case for why this is called? It has to be called
before the module frees the kallsyms. It's for tracing the module's
init functions.
cd /sys/kernel/tracing
echo :mod:<module> > set_ftrace_filter
echo function > current_tracer
modprobe <module>
cat trace
You should see the init functions of the module loaded. If
ftrace_free_mem() is called after the module frees the kallsyms of the
module init functions, you'll just get garbage for the init function
names.
> mutex_lock(&module_mutex);
> /* Drop initial reference. */
> module_put(mod);
> @@ -3131,7 +3127,6 @@ static noinline int do_init_module(struct module *mod)
> blocking_notifier_call_chain(&module_notify_list,
> MODULE_STATE_GOING, mod);
> klp_module_going(mod);
> - ftrace_release_mod(mod);
> free_module(mod);
> wake_up_all(&module_wq);
>
> @@ -3278,7 +3273,6 @@ static int prepare_coming_module(struct module *mod)
> {
> int err;
>
> - ftrace_module_enable(mod);
> err = klp_module_coming(mod);
Same issue with ftrace and klp here.
> if (err)
> return err;
> @@ -3461,7 +3455,8 @@ static int load_module(struct load_info *info, const char __user *uargs,
> init_build_id(mod, info);
>
> /* Ftrace init must be called in the MODULE_STATE_UNFORMED state */
> - ftrace_module_init(mod);
> + blocking_notifier_call_chain(&module_notify_list,
> + MODULE_STATE_UNFORMED, mod);
>
> /* Finally it's fully formed, ready to start executing. */
> err = complete_formation(mod, info);
> @@ -3513,8 +3508,6 @@ static int load_module(struct load_info *info, const char __user *uargs,
> coming_cleanup:
> mod->state = MODULE_STATE_GOING;
> destroy_params(mod->kp, mod->num_kp);
> - blocking_notifier_call_chain(&module_notify_list,
> - MODULE_STATE_GOING, mod);
> klp_module_going(mod);
Now klp_module_going() may need to be called *after* the
MODULE_STATE_GOING callbacks and *before* ftrace_release_mod(). But
again, if that's moved into ftrace_release_mod() it may be fine.
> bug_cleanup:
> mod->state = MODULE_STATE_GOING;
> @@ -3524,7 +3517,8 @@ static int load_module(struct load_info *info, const char __user *uargs,
> mutex_unlock(&module_mutex);
>
> ddebug_cleanup:
> - ftrace_release_mod(mod);
> + blocking_notifier_call_chain(&module_notify_list,
> + MODULE_STATE_GOING, mod);
> synchronize_rcu();
> kfree(mod->args);
> free_arch_cleanup:
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
-- Steve
^ permalink raw reply
* Re: IMA and PQC
From: Eric Biggers @ 2026-02-26 0:10 UTC (permalink / raw)
To: Stefan Berger
Cc: Coiby Xu, Johannes Wiesböck, dhowells, dmitry.kasatkin,
eric.snowberg, keyrings, linux-crypto, linux-integrity,
linux-kernel, linux-modules, roberto.sassu, simo, zohar,
michael.weiss
In-Reply-To: <ee36981d-d658-4296-9acb-874c72606b3e@linux.ibm.com>
On Wed, Feb 25, 2026 at 09:25:43AM -0500, Stefan Berger wrote:
> To avoid duplicate work: Is either one of you planning on writing patches
> for IMA to use ML-DSA and convert the current ML-DSA to also support HashML?
> I had done the work on this before and could dig out the patches again...
IMA already had to add its own digest prefixing support, since it was
needed to disambiguate between full-file digests and fsverity digests.
See 'struct ima_file_id'. Thus the message signed is at most 66 bytes.
With that being the case, HashML-DSA isn't necessary. It's not even
possible to use here, since there are no OIDs assigned for the fsverity
digests, so it cannot replace the ima_file_id.
I'll also note that HashML-DSA is controversial (e.g. see
https://keymaterial.net/2024/11/05/hashml-dsa-considered-harmful/),
since it was added to the ML-DSA specification at a late stage without
sufficient review, and what it does can be achieved in better ways.
Which is exactly what we are seeing here, since again, IMA needs to do
the digest calculation and prefixing itself anyway.
- Eric
^ permalink raw reply
* RE: [PATCH 17/17] Add standalone crypto kernel module technical documentation
From: Jay Wang @ 2026-02-25 17:35 UTC (permalink / raw)
To: ebiggers
Cc: bp, catalin.marinas, davem, herbert, ilya.okomin,
jay.wang.upstream, linux-arm-kernel, linux-crypto, linux-kbuild,
linux-modules, mcgrof, mingo, nathan, nsc, nstange, petr.pavlu,
tglx, vegard.nossum, wanjay, will, x86
In-Reply-To: <20260225015517.GA162634@quark>
Thanks to everyone who has taken the time to review and comment.
Based on the discussion so far, it seems the core question is whether this feature is appropriate for upstream at all, or whether it should remain entirely downstream.
We’ve discussed this with a few folks, and to help clarify the discussion, let me outline what is actually required to use this approach and what the community would gain from upstreaming it:
1. Maintaining a crypto snapshot (for example, a source code snapshot used for streamlined FIPS re-validation processes such as NSRL).
2. Maintaining the loadable crypto build infrastructure itself (i.e., this patch set).
For (1), since this requires maintaining a specific snapshot, we acknowledge that this is inherently a downstream responsibility. We are not expecting upstream to provide or guarantee a stable in-kernel API (to clarify, a stable ABI is not strictly required here, since the crypto module can be rebuilt against newer kernels and still benefit from FIPS through the shorter NSRL re-validation process of roughly 3 months, compared to the full 12–18 month certification cycle). The upstream crypto subsystem should continue evolving independently.
For (2), since this feature mainly serves as infrastructure and is of interest to multiple distributions, upstreaming it could help reduce the effort each distribution would otherwise spend maintaining similar infrastructure patches independently.
We’d love to hear more thoughts on this. If the general consensus is that the downsides outweigh the benefits of merging this into mainline, we are happy to maintain it in a separate repository tracking the latest mainline and stable releases in order to keep the work publicly available.
Thanks again for taking the time to read and discuss this.
Jay
^ permalink raw reply
* Re: IMA and PQC
From: Stefan Berger @ 2026-02-25 14:25 UTC (permalink / raw)
To: Coiby Xu, Johannes Wiesböck
Cc: dhowells, dmitry.kasatkin, ebiggers, eric.snowberg, keyrings,
linux-crypto, linux-integrity, linux-kernel, linux-modules,
roberto.sassu, simo, zohar, michael.weiss
In-Reply-To: <aYHznG6vbptVOjHQ@Rk>
On 2/3/26 8:32 AM, Coiby Xu wrote:
> On Fri, Jan 30, 2026 at 09:31:26PM +0100, Johannes Wiesböck wrote:
>> Hi all,
>
> Hi Johannes,
>
>>
>> we conducted an evaluation regarding PQC use in IMA last year (see [1]
>> for all
>> details) where we also considered the interplay of different PQC
>> signatures and
>> file systems (ext4, btrfs, XFS, f2fs).
>
> Thanks for sharing this comprehensive study! There are many nuances in
> this research paper!
>
>>
>> Coiby Xu <coxu@redhat.com> wrote:
>>
>>> According to my experiments done so far, for verification speed,
>>> ML-DSA-65 is consistently faster than ECDSA P-384 which is used by
>>> current CentOS/RHEL to sign files in a package.
>>
>> Regarding performance, similar to Coiby, we found that all variants of
>> ML-DSA
>> consistently outperformed ECDSA P-256.
>
> Glad to know ML-DSA is also faster than ECDSA P-256!
To avoid duplicate work: Is either one of you planning on writing
patches for IMA to use ML-DSA and convert the current ML-DSA to also
support HashML? I had done the work on this before and could dig out the
patches again...
Stefan
^ permalink raw reply
* Re: [PATCH 17/17] Add standalone crypto kernel module technical documentation
From: Christoph Hellwig @ 2026-02-25 14:08 UTC (permalink / raw)
To: Eric Biggers
Cc: Jay Wang, Herbert Xu, David S . Miller, linux-crypto, Jay Wang,
Vegard Nossum, Nicolai Stange, Ilia Okomin, Catalin Marinas,
Will Deacon, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Luis Chamberlain, Petr Pavlu, Nathan Chancellor, Nicolas Schier,
linux-arm-kernel, x86, linux-kbuild, linux-modules
In-Reply-To: <20260225015517.GA162634@quark>
On Tue, Feb 24, 2026 at 05:55:17PM -0800, Eric Biggers wrote:
> Let's be clear: this is possible only when the kernel has a stable ABI
> to the crypto module, which realistically isn't something that is going
> to be supported upstream. The Linux kernel is well-known for not
> maintaining a stable in-kernel ABI, for good reasons.
>
> So, the only case where this feature would have a benefit over the
> kernel's existing approach to FIPS 140 is in downstream kernels that
> maintain a stable in-kernel ABI. There would be no benefit to direct
> users of the mainline kernel or even the stable release series.
>
> For this to be considered for upstream there would need to be some level
> of consensus in the community to support this feature despite this.
That's a very nice way to say this goes against all the established
principles for kernel development.
^ permalink raw reply
* [PATCH] kernel/trace/ftrace: introduce ftrace module notifier
From: chensong_2000 @ 2026-02-25 5:46 UTC (permalink / raw)
To: mcgrof, petr.pavlu, da.gomez, samitolvanen, atomlin, rostedt,
mhiramat, mark.rutland, mathieu.desnoyers
Cc: linux-modules, linux-kernel, linux-trace-kernel, Song Chen
From: Song Chen <chensong_2000@189.cn>
Like kprobe, fprobe and btf, this patch attempts to introduce
a notifier_block for ftrace to decouple its initialization from
load_module.
Below is the table of ftrace fucntions calls in different
module state:
MODULE_STATE_UNFORMED ftrace_module_init
MODULE_STATE_COMING ftrace_module_enable
MODULE_STATE_LIVE ftrace_free_mem
MODULE_STATE_GOING ftrace_release_mod
Unlike others, ftrace module notifier must take care of state
MODULE_STATE_UNFORMED to ensure calling ftrace_module_init
before complete_formation which changes module's text property.
That pretty much remains same logic with its original design,
the only thing that changes is blocking_notifier_call_chain
(MODULE_STATE_GOING) has to be moved from coming_cleanup to
ddebug_cleanup in function load_module to ensure
ftrace_release_mod is invoked in case complete_formation fails.
Signed-off-by: Song Chen <chensong_2000@189.cn>
---
kernel/module/main.c | 14 ++++----------
kernel/trace/ftrace.c | 37 +++++++++++++++++++++++++++++++++++++
2 files changed, 41 insertions(+), 10 deletions(-)
diff --git a/kernel/module/main.c b/kernel/module/main.c
index 710ee30b3bea..5dc0a980e9bd 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -45,7 +45,6 @@
#include <linux/license.h>
#include <asm/sections.h>
#include <linux/tracepoint.h>
-#include <linux/ftrace.h>
#include <linux/livepatch.h>
#include <linux/async.h>
#include <linux/percpu.h>
@@ -836,7 +835,6 @@ SYSCALL_DEFINE2(delete_module, const char __user *, name_user,
blocking_notifier_call_chain(&module_notify_list,
MODULE_STATE_GOING, mod);
klp_module_going(mod);
- ftrace_release_mod(mod);
async_synchronize_full();
@@ -3067,8 +3065,6 @@ static noinline int do_init_module(struct module *mod)
if (!mod->async_probe_requested)
async_synchronize_full();
- ftrace_free_mem(mod, mod->mem[MOD_INIT_TEXT].base,
- mod->mem[MOD_INIT_TEXT].base + mod->mem[MOD_INIT_TEXT].size);
mutex_lock(&module_mutex);
/* Drop initial reference. */
module_put(mod);
@@ -3131,7 +3127,6 @@ static noinline int do_init_module(struct module *mod)
blocking_notifier_call_chain(&module_notify_list,
MODULE_STATE_GOING, mod);
klp_module_going(mod);
- ftrace_release_mod(mod);
free_module(mod);
wake_up_all(&module_wq);
@@ -3278,7 +3273,6 @@ static int prepare_coming_module(struct module *mod)
{
int err;
- ftrace_module_enable(mod);
err = klp_module_coming(mod);
if (err)
return err;
@@ -3461,7 +3455,8 @@ static int load_module(struct load_info *info, const char __user *uargs,
init_build_id(mod, info);
/* Ftrace init must be called in the MODULE_STATE_UNFORMED state */
- ftrace_module_init(mod);
+ blocking_notifier_call_chain(&module_notify_list,
+ MODULE_STATE_UNFORMED, mod);
/* Finally it's fully formed, ready to start executing. */
err = complete_formation(mod, info);
@@ -3513,8 +3508,6 @@ static int load_module(struct load_info *info, const char __user *uargs,
coming_cleanup:
mod->state = MODULE_STATE_GOING;
destroy_params(mod->kp, mod->num_kp);
- blocking_notifier_call_chain(&module_notify_list,
- MODULE_STATE_GOING, mod);
klp_module_going(mod);
bug_cleanup:
mod->state = MODULE_STATE_GOING;
@@ -3524,7 +3517,8 @@ static int load_module(struct load_info *info, const char __user *uargs,
mutex_unlock(&module_mutex);
ddebug_cleanup:
- ftrace_release_mod(mod);
+ blocking_notifier_call_chain(&module_notify_list,
+ MODULE_STATE_GOING, mod);
synchronize_rcu();
kfree(mod->args);
free_arch_cleanup:
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 3ec2033c0774..47c74d4a2425 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -5223,6 +5223,43 @@ static int __init ftrace_mod_cmd_init(void)
}
core_initcall(ftrace_mod_cmd_init);
+static int ftrace_module_callback(struct notifier_block *nb, unsigned long op,
+ void *module)
+{
+ struct module *mod = module;
+
+ switch (op) {
+ case MODULE_STATE_UNFORMED:
+ ftrace_module_init(mod);
+ break;
+ case MODULE_STATE_COMING:
+ ftrace_module_enable(mod);
+ break;
+ case MODULE_STATE_LIVE:
+ ftrace_free_mem(mod, mod->mem[MOD_INIT_TEXT].base,
+ mod->mem[MOD_INIT_TEXT].base + mod->mem[MOD_INIT_TEXT].size);
+ break;
+ case MODULE_STATE_GOING:
+ ftrace_release_mod(mod);
+ break;
+ default:
+ break;
+ }
+
+ return notifier_from_errno(0);
+}
+
+static struct notifier_block ftrace_module_nb = {
+ .notifier_call = ftrace_module_callback,
+ .priority = 0
+};
+
+static int __init ftrace_register_module_notifier(void)
+{
+ return register_module_notifier(&ftrace_module_nb);
+}
+core_initcall(ftrace_register_module_notifier);
+
static void function_trace_probe_call(unsigned long ip, unsigned long parent_ip,
struct ftrace_ops *op, struct ftrace_regs *fregs)
{
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 17/17] Add standalone crypto kernel module technical documentation
From: Eric Biggers @ 2026-02-25 1:55 UTC (permalink / raw)
To: Jay Wang
Cc: Herbert Xu, David S . Miller, linux-crypto, Jay Wang,
Vegard Nossum, Nicolai Stange, Ilia Okomin, Catalin Marinas,
Will Deacon, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Luis Chamberlain, Petr Pavlu, Nathan Chancellor, Nicolas Schier,
linux-arm-kernel, x86, linux-kbuild, linux-modules
In-Reply-To: <20260212024228.6267-18-wanjay@amazon.com>
On Thu, Feb 12, 2026 at 02:42:21AM +0000, Jay Wang wrote:
> With this feature, FIPS certification is tied only to the crypto
> module. Therefore, once the module is certified, loading this
> certified module on newer kernels automatically makes those kernels
> FIPS-certified. As a result, this approach can save re-certification
> costs and 12-18 months of waiting time by reducing the need for
> repeated FIPS re-certification cycles.
Let's be clear: this is possible only when the kernel has a stable ABI
to the crypto module, which realistically isn't something that is going
to be supported upstream. The Linux kernel is well-known for not
maintaining a stable in-kernel ABI, for good reasons.
So, the only case where this feature would have a benefit over the
kernel's existing approach to FIPS 140 is in downstream kernels that
maintain a stable in-kernel ABI. There would be no benefit to direct
users of the mainline kernel or even the stable release series.
For this to be considered for upstream there would need to be some level
of consensus in the community to support this feature despite this.
- Eric
^ permalink raw reply
* Re: [PATCH] module: Fix kernel panic when a symbol st_shndx is out of bounds
From: Sami Tolvanen @ 2026-02-24 18:34 UTC (permalink / raw)
To: Luis Chamberlain, Petr Pavlu, Daniel Gomez, Nathan Chancellor,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Ihor Solodrai
Cc: linux-kernel, linux-modules, bpf, linux-kbuild, llvm
In-Reply-To: <20251230183208.1317279-1-ihor.solodrai@linux.dev>
On Tue, 30 Dec 2025 10:32:08 -0800, Ihor Solodrai wrote:
> The module loader doesn't check for bounds of the ELF section index in
> simplify_symbols():
>
> for (i = 1; i < symsec->sh_size / sizeof(Elf_Sym); i++) {
> const char *name = info->strtab + sym[i].st_name;
>
> switch (sym[i].st_shndx) {
> case SHN_COMMON:
>
> [...]
Applied to modules-next, thanks!
[1/1] module: Fix kernel panic when a symbol st_shndx is out of bounds
commit: f9d69d5e7bde2295eb7488a56f094ac8f5383b92
Best regards,
Sami
^ permalink raw reply
* Re: [PATCH] module: Remove duplicate freeing of lockdep classes
From: Sami Tolvanen @ 2026-02-24 18:34 UTC (permalink / raw)
To: Luis Chamberlain, Daniel Gomez, Petr Pavlu
Cc: Aaron Tomlin, Peter Zijlstra, Ingo Molnar, Will Deacon,
Waiman Long, Song Liu, linux-modules, linux-kernel, Boqun Feng
In-Reply-To: <20260107122329.1324707-1-petr.pavlu@suse.com>
On Wed, 07 Jan 2026 13:22:57 +0100, Petr Pavlu wrote:
> In the error path of load_module(), under the free_module label, the
> code calls lockdep_free_key_range() to release lock classes associated
> with the MOD_DATA, MOD_RODATA and MOD_RO_AFTER_INIT module regions, and
> subsequently invokes module_deallocate().
>
> Since commit ac3b43283923 ("module: replace module_layout with
> module_memory"), the module_deallocate() function calls free_mod_mem(),
> which releases the lock classes as well and considers all module
> regions.
>
> [...]
Applied to modules-next, thanks!
[1/1] module: Remove duplicate freeing of lockdep classes
commit: a7b4bc094fbaa7dc7b7b91ae33549bbd7eefaac1
Best regards,
Sami
^ permalink raw reply
* Re: [PATCH] module: Fix the modversions and signing submenus
From: Sami Tolvanen @ 2026-02-24 18:34 UTC (permalink / raw)
To: Luis Chamberlain, Daniel Gomez, Petr Pavlu
Cc: Aaron Tomlin, linux-modules, linux-kernel
In-Reply-To: <20260205143720.423026-1-petr.pavlu@suse.com>
On Thu, 05 Feb 2026 15:37:08 +0100, Petr Pavlu wrote:
> The module Kconfig file contains a set of options related to "Module
> versioning support" (depends on MODVERSIONS) and "Module signature
> verification" (depends on MODULE_SIG). The Kconfig tool automatically
> creates submenus when an entry for a symbol is followed by consecutive
> items that all depend on the symbol. However, this functionality doesn't
> work for the mentioned module options. The MODVERSIONS options are
> interleaved with ASM_MODVERSIONS, which has no 'depends on MODVERSIONS' but
> instead uses 'default HAVE_ASM_MODVERSIONS && MODVERSIONS'. Similarly, the
> MODULE_SIG options are interleaved by a comment warning not to forget
> signing modules with scripts/sign-file, which uses the condition 'depends
> on MODULE_SIG_FORCE && !MODULE_SIG_ALL'.
>
> [...]
Applied to modules-next, thanks!
[1/1] module: Fix the modversions and signing submenus
commit: 8d597ba6ec18dae2eec143d4e1c9d81441ca0dda
Best regards,
Sami
^ permalink raw reply
* Re: [PATCH v4 15/17] module: Introduce hash-based integrity checking
From: Nicolas Schier @ 2026-02-24 16:14 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Nathan Chancellor, Arnd Bergmann, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, Daniel Gomez, Paul Moore, James Morris,
Serge E. Hallyn, Jonathan Corbet, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Naveen N Rao, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Daniel Gomez,
Aaron Tomlin, Christophe Leroy (CS GROUP), Nicolas Bouchinet,
Xiu Jianfeng, Fabian Grünbichler, Arnout Engelen,
Mattia Rizzolo, kpcyrd, Christian Heusel, Câju Mihai-Drosi,
Sebastian Andrzej Siewior, linux-kbuild, linux-kernel, linux-arch,
linux-modules, linux-security-module, linux-doc, linuxppc-dev,
linux-integrity
In-Reply-To: <06054e9a-2b7a-4063-98b8-7d6c539e543f@t-8ch.de>
On Mon, Feb 23, 2026 at 10:43:30PM +0100, Thomas Weißschuh wrote:
> On 2026-02-23 19:41:52+0100, Nicolas Schier wrote:
> > On Mon, Feb 23, 2026 at 08:53:29AM +0100, Thomas Weißschuh wrote:
> > > On 2026-02-21 22:38:29+0100, Nicolas Schier wrote:
> > > > On Tue, Jan 13, 2026 at 01:28:59PM +0100, Thomas Weißschuh wrote:
[...]
> > > > [...]
> > > > > diff --git a/scripts/modules-merkle-tree.c b/scripts/modules-merkle-tree.c
> > > > > new file mode 100644
> > > > > index 000000000000..a6ec0e21213b
> > > > > --- /dev/null
> > > > > +++ b/scripts/modules-merkle-tree.c
> > > > > @@ -0,0 +1,467 @@
> > > > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > > > +/*
> > > > > + * Compute hashes for modules files and build a merkle tree.
> > > > > + *
> > > > > + * Copyright (C) 2025 Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
> > > > > + * Copyright (C) 2025 Thomas Weißschuh <linux@weissschuh.net>
> > > > > + *
> > > > > + */
> > > > > +#define _GNU_SOURCE 1
> > > > > +#include <arpa/inet.h>
> > > > > +#include <err.h>
> > > > > +#include <unistd.h>
> > > > > +#include <fcntl.h>
> > > > > +#include <stdarg.h>
> > > > > +#include <stdio.h>
> > > > > +#include <string.h>
> > > > > +#include <stdbool.h>
> > > > > +#include <stdlib.h>
> > > > > +
> > > > > +#include <sys/stat.h>
> > > > > +#include <sys/mman.h>
> > > > > +
> > > > > +#include <openssl/evp.h>
> > > > > +#include <openssl/err.h>
> > > > > +
> > > > > +#include "ssl-common.h"
> > > > > +
> > > > > +static int hash_size;
> > > > > +static EVP_MD_CTX *ctx;
> > > > > +
> > > > > +struct module_signature {
> > > > > + uint8_t algo; /* Public-key crypto algorithm [0] */
> > > > > + uint8_t hash; /* Digest algorithm [0] */
> > > > > + uint8_t id_type; /* Key identifier type [PKEY_ID_PKCS7] */
> > > > > + uint8_t signer_len; /* Length of signer's name [0] */
> > > > > + uint8_t key_id_len; /* Length of key identifier [0] */
> > > > > + uint8_t __pad[3];
> > > > > + uint32_t sig_len; /* Length of signature data */
> > > > > +};
> > > > > +
> > > > > +#define PKEY_ID_MERKLE 3
> > > > > +
> > > > > +static const char magic_number[] = "~Module signature appended~\n";
> > > >
> > > > This here will be the forth definition of struct module_signature,
> > > > increasing the risk of unwanted diversion. I second Petr's suggestion
> > > > to reuse a _common_ definition instead.
> > >
> > > Ack.
> > >
> > > > (Here, even include/linux/module_signature.h could be included itself.)
> > >
> > > I'd like to avoid including internal headers from other components.
> > > We could move it to an UAPI header. Various other subsystems use those
> > > for not-really-UAPI but still ABI definitions.
> >
> > Yeah, ack.
>
> What exactly is the 'ack' for?
> * Avoiding to include internal headers?
> * Moving the definition to UAPI headers?
ah, sorry. I think reduction of duplicated definitions is good; moving
these definitions to UAPI headers sounds like a valid compromise to me.
> (...)
>
> > > > Can you verify if I get the mechanics roughly correct?
> > > >
> > > > * Modules are merkle tree leaves. Modules are built and logically
> > > > paired by the order from modules.order; a single left-over module is
> > > > paired with itself.
> > > >
> > > > * Hashes of paired modules are hashed again (branch node hash);
> > > > hashes of pairs of branch nodes' hashes are hashed again;
> > > > repeat until we reach the single merkle tree root hash
> > > >
> > > > * The final merkle tree root hash (and the count of tree levels) is
> > > > included in vmlinux
> > >
> > > The merkle tree code was written by Sebastian so he will have the best
> > > knowledge about it. But this is also my understanding.
> >
> > I'd like to see some (rough) description in Documentation or in a commit
> > message at least, otherwise future me will have to ask that again.
>
> Ack in general. I'd prefer to document it in a source code comment,
> though. That feels like the best fit to me.
Great, thanks.
--
Nicolas
^ permalink raw reply
* Re: [PATCH] builtin: mark __builtin_strlen() as integer constant expression
From: Andy Shevchenko @ 2026-02-24 10:26 UTC (permalink / raw)
To: Chris Li
Cc: Daniel Gomez, Al Viro, Sami Tolvanen, linux-sparse, Aaron Tomlin,
Dan Carpenter, Dmitry Torokhov, Eric Biggers, linux-kernel,
linux-modules, Luck, Tony, Luis Chamberlain, Petr Pavlu
In-Reply-To: <CACePvbU5ByoP2jZZSHYWCncNNXOQXArvyWpVcinTRag8k3-GiA@mail.gmail.com>
On Fri, Feb 20, 2026 at 11:34:29AM -0800, Chris Li wrote:
> On Fri, Feb 20, 2026 at 12:31 AM Andy Shevchenko
> <andriy.shevchenko@intel.com> wrote:
> > On Fri, Feb 20, 2026 at 12:06:15AM -0800, Chris Li wrote:
> > > On Thu, Feb 19, 2026 at 11:20 AM Andy Shevchenko
> > > <andriy.shevchenko@intel.com> wrote:
> > > > On Thu, Feb 19, 2026 at 09:06:23AM -0800, Chris Li wrote:
> > > > > On Thu, Feb 19, 2026 at 9:00 AM Daniel Gomez <da.gomez@kernel.org> wrote:
> > > > > >
> > > > > > Can you please take a look? If Al patch is the correct approach, any
> > > > > > chance you can send it and fix this?
> > > > >
> > > > > I am asking in another thread should I pull Al's git repo instead.
> > > > > There are a few good commits there.
> > > >
> > > > Please, pull Al's work, My colleagues and I use his version of sparse for a few
> > > > weeks without noticing any downsides.
> > >
> > > Thanks for the heads up. I just pulled Al's sparse repo.
> >
> > Can you also issue a new tag (say 0.6.5) so the distros can really be pushed to
> > update the quite outdated sparse in their repos?
>
> Sure. I can give it a spin this weekend and keep you posted. There is
> one risk on my signing key, it might be expired and I need to sort
> that out.
>
> Meanwhile, please give the current sparse repo some good tests.
It seems that your tip is the same as Al's, and if it's the case
we are testing (actually using) this for a few weeks without problems.
Thanks!
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 15/17] module: Introduce hash-based integrity checking
From: Thomas Weißschuh @ 2026-02-23 21:43 UTC (permalink / raw)
To: Nicolas Schier, Nathan Chancellor, Arnd Bergmann,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Daniel Gomez,
Paul Moore, James Morris, Serge E. Hallyn, Jonathan Corbet,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Naveen N Rao, Mimi Zohar, Roberto Sassu, Dmitry Kasatkin,
Eric Snowberg, Daniel Gomez, Aaron Tomlin,
Christophe Leroy (CS GROUP), Nicolas Bouchinet, Xiu Jianfeng,
Fabian Grünbichler, Arnout Engelen, Mattia Rizzolo, kpcyrd,
Christian Heusel, Câju Mihai-Drosi,
Sebastian Andrzej Siewior, linux-kbuild, linux-kernel, linux-arch,
linux-modules, linux-security-module, linux-doc, linuxppc-dev,
linux-integrity
In-Reply-To: <aZyfcDCWOBJJztQ2@levanger>
On 2026-02-23 19:41:52+0100, Nicolas Schier wrote:
> On Mon, Feb 23, 2026 at 08:53:29AM +0100, Thomas Weißschuh wrote:
> > On 2026-02-21 22:38:29+0100, Nicolas Schier wrote:
> > > On Tue, Jan 13, 2026 at 01:28:59PM +0100, 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 signing key is used, which precludes rebuilds by third parties
> > > > and makes the whole build and packaging process much more complicated.
> > > >
> > > > The goal is to reach bit-for-bit reproducibility. Excluding certain
> > > > parts of the build output from the reproducibility analysis would be
> > > > error-prone and force each downstream consumer to introduce new tooling.
> > > >
> > > > Introduce a new mechanism to ensure only well-known modules are loaded
> > > > by embedding a merkle tree root 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 build a merkle tree. This introduces a dependency cycle which is
> > > > impossible to satisfy. 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
> > > >
> > > > The PKCS7 format which is used for regular module signatures can not
> > > > represent Merkle proofs, so a new kind of module signature is
> > > > introduced. As this signature type is only ever used for builtin
> > > > modules, no compatibility issues can arise.
> > > >
> > > > 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 | 25 ++
> > > > include/linux/module_signature.h | 1 +
> > > > kernel/module/Kconfig | 21 +-
> > > > kernel/module/Makefile | 1 +
> > > > kernel/module/hashes.c | 92 ++++++
> > > > kernel/module/hashes_root.c | 6 +
> > > > kernel/module/internal.h | 1 +
> > > > kernel/module/main.c | 4 +-
> > > > scripts/.gitignore | 1 +
> > > > scripts/Makefile | 3 +
> > > > scripts/Makefile.modfinal | 11 +
> > > > scripts/Makefile.modinst | 13 +
> > > > scripts/Makefile.vmlinux | 5 +
> > > > scripts/link-vmlinux.sh | 14 +-
> > > > scripts/modules-merkle-tree.c | 467 +++++++++++++++++++++++++++
> > > > security/lockdown/Kconfig | 2 +-
> > > > 20 files changed, 685 insertions(+), 7 deletions(-)
> > > >
> > > [...]
> > >
> > > > diff --git a/kernel/module/hashes_root.c b/kernel/module/hashes_root.c
> > > > new file mode 100644
> > > > index 000000000000..1abfcd3aa679
> > > > --- /dev/null
> > > > +++ b/kernel/module/hashes_root.c
> > > > @@ -0,0 +1,6 @@
> > > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > > +
> > > > +#include <linux/module_hashes.h>
> > > > +
> > > > +/* Blank dummy data. Will be overridden by link-vmlinux.sh */
> > > > +const struct module_hashes_root module_hashes_root __module_hashes_section = {};
> > > > diff --git a/kernel/module/internal.h b/kernel/module/internal.h
> > > > index e2d49122c2a1..e22837d3ac76 100644
> > > > --- a/kernel/module/internal.h
> > > > +++ b/kernel/module/internal.h
> > > > @@ -338,6 +338,7 @@ void module_mark_ro_after_init(const Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
> > > > const char *secstrings);
> > > >
> > > > int module_sig_check(struct load_info *info, const u8 *sig, size_t sig_len);
> > > > +int module_hash_check(struct load_info *info, const u8 *sig, size_t sig_len);
> > > >
> > > > #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 2a28a0ece809..fa30b6387936 100644
> > > > --- a/kernel/module/main.c
> > > > +++ b/kernel/module/main.c
> > > > @@ -3362,8 +3362,10 @@ static int module_integrity_check(struct load_info *info, int flags)
> > > >
> > > > if (IS_ENABLED(CONFIG_MODULE_SIG) && sig_type == PKEY_ID_PKCS7) {
> > > > err = module_sig_check(info, sig, sig_len);
> > > > + } else if (IS_ENABLED(CONFIG_MODULE_HASHES) && sig_type == PKEY_ID_MERKLE) {
> > > > + err = module_hash_check(info, sig, sig_len);
> > > > } else {
> > > > - pr_err("module: not signed with expected PKCS#7 message\n");
> > > > + pr_err("module: not signed with signature mechanism\n");
> > > > err = -ENOPKG;
> > >
> > > To prevent others from running into the same issue:
> > >
> > > My first test got stuck here, as I tested with virtme-ng, which symlinks
> > > modules from build tree to /lib/modules/$(uname -r)/..., resulting in
> > >
> > > [ 15.956855] module: not signed with signature mechanism
> > > modprobe: ERROR: could not insert 'efivarfs': Package not installed
> > >
> > > As the modules_install step was missing, modules were not being signed.
> >
> > Currently the signing is deferred to installation time to keep in sync
> > with regular module signing and to keep the logic simpler by not having
> > to gracefully handle previously-signed files.
> > But this could be changed.
>
> I did not want to suggest changing the behaviour, that would make things
> more complicated to prevent needless rebuilds. I just wanted to mention
> it here to prevent others from burning time.
Understood.
> > > [...]
> > > > diff --git a/scripts/modules-merkle-tree.c b/scripts/modules-merkle-tree.c
> > > > new file mode 100644
> > > > index 000000000000..a6ec0e21213b
> > > > --- /dev/null
> > > > +++ b/scripts/modules-merkle-tree.c
> > > > @@ -0,0 +1,467 @@
> > > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > > +/*
> > > > + * Compute hashes for modules files and build a merkle tree.
> > > > + *
> > > > + * Copyright (C) 2025 Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
> > > > + * Copyright (C) 2025 Thomas Weißschuh <linux@weissschuh.net>
> > > > + *
> > > > + */
> > > > +#define _GNU_SOURCE 1
> > > > +#include <arpa/inet.h>
> > > > +#include <err.h>
> > > > +#include <unistd.h>
> > > > +#include <fcntl.h>
> > > > +#include <stdarg.h>
> > > > +#include <stdio.h>
> > > > +#include <string.h>
> > > > +#include <stdbool.h>
> > > > +#include <stdlib.h>
> > > > +
> > > > +#include <sys/stat.h>
> > > > +#include <sys/mman.h>
> > > > +
> > > > +#include <openssl/evp.h>
> > > > +#include <openssl/err.h>
> > > > +
> > > > +#include "ssl-common.h"
> > > > +
> > > > +static int hash_size;
> > > > +static EVP_MD_CTX *ctx;
> > > > +
> > > > +struct module_signature {
> > > > + uint8_t algo; /* Public-key crypto algorithm [0] */
> > > > + uint8_t hash; /* Digest algorithm [0] */
> > > > + uint8_t id_type; /* Key identifier type [PKEY_ID_PKCS7] */
> > > > + uint8_t signer_len; /* Length of signer's name [0] */
> > > > + uint8_t key_id_len; /* Length of key identifier [0] */
> > > > + uint8_t __pad[3];
> > > > + uint32_t sig_len; /* Length of signature data */
> > > > +};
> > > > +
> > > > +#define PKEY_ID_MERKLE 3
> > > > +
> > > > +static const char magic_number[] = "~Module signature appended~\n";
> > >
> > > This here will be the forth definition of struct module_signature,
> > > increasing the risk of unwanted diversion. I second Petr's suggestion
> > > to reuse a _common_ definition instead.
> >
> > Ack.
> >
> > > (Here, even include/linux/module_signature.h could be included itself.)
> >
> > I'd like to avoid including internal headers from other components.
> > We could move it to an UAPI header. Various other subsystems use those
> > for not-really-UAPI but still ABI definitions.
>
> Yeah, ack.
What exactly is the 'ack' for?
* Avoiding to include internal headers?
* Moving the definition to UAPI headers?
(...)
> > > Can you verify if I get the mechanics roughly correct?
> > >
> > > * Modules are merkle tree leaves. Modules are built and logically
> > > paired by the order from modules.order; a single left-over module is
> > > paired with itself.
> > >
> > > * Hashes of paired modules are hashed again (branch node hash);
> > > hashes of pairs of branch nodes' hashes are hashed again;
> > > repeat until we reach the single merkle tree root hash
> > >
> > > * The final merkle tree root hash (and the count of tree levels) is
> > > included in vmlinux
> >
> > The merkle tree code was written by Sebastian so he will have the best
> > knowledge about it. But this is also my understanding.
>
> I'd like to see some (rough) description in Documentation or in a commit
> message at least, otherwise future me will have to ask that again.
Ack in general. I'd prefer to document it in a source code comment,
though. That feels like the best fit to me.
Thomas
^ permalink raw reply
* Re: [PATCH v4 15/17] module: Introduce hash-based integrity checking
From: Nicolas Schier @ 2026-02-23 18:41 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Nathan Chancellor, Arnd Bergmann, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, Daniel Gomez, Paul Moore, James Morris,
Serge E. Hallyn, Jonathan Corbet, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Naveen N Rao, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Daniel Gomez,
Aaron Tomlin, Christophe Leroy (CS GROUP), Nicolas Bouchinet,
Xiu Jianfeng, Fabian Grünbichler, Arnout Engelen,
Mattia Rizzolo, kpcyrd, Christian Heusel, Câju Mihai-Drosi,
Sebastian Andrzej Siewior, linux-kbuild, linux-kernel, linux-arch,
linux-modules, linux-security-module, linux-doc, linuxppc-dev,
linux-integrity
In-Reply-To: <0d70db8d-702b-46ec-a010-298fe6515aab@t-8ch.de>
On Mon, Feb 23, 2026 at 08:53:29AM +0100, Thomas Weißschuh wrote:
> On 2026-02-21 22:38:29+0100, Nicolas Schier wrote:
> > On Tue, Jan 13, 2026 at 01:28:59PM +0100, 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 signing key is used, which precludes rebuilds by third parties
> > > and makes the whole build and packaging process much more complicated.
> > >
> > > The goal is to reach bit-for-bit reproducibility. Excluding certain
> > > parts of the build output from the reproducibility analysis would be
> > > error-prone and force each downstream consumer to introduce new tooling.
> > >
> > > Introduce a new mechanism to ensure only well-known modules are loaded
> > > by embedding a merkle tree root 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 build a merkle tree. This introduces a dependency cycle which is
> > > impossible to satisfy. 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
> > >
> > > The PKCS7 format which is used for regular module signatures can not
> > > represent Merkle proofs, so a new kind of module signature is
> > > introduced. As this signature type is only ever used for builtin
> > > modules, no compatibility issues can arise.
> > >
> > > 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 | 25 ++
> > > include/linux/module_signature.h | 1 +
> > > kernel/module/Kconfig | 21 +-
> > > kernel/module/Makefile | 1 +
> > > kernel/module/hashes.c | 92 ++++++
> > > kernel/module/hashes_root.c | 6 +
> > > kernel/module/internal.h | 1 +
> > > kernel/module/main.c | 4 +-
> > > scripts/.gitignore | 1 +
> > > scripts/Makefile | 3 +
> > > scripts/Makefile.modfinal | 11 +
> > > scripts/Makefile.modinst | 13 +
> > > scripts/Makefile.vmlinux | 5 +
> > > scripts/link-vmlinux.sh | 14 +-
> > > scripts/modules-merkle-tree.c | 467 +++++++++++++++++++++++++++
> > > security/lockdown/Kconfig | 2 +-
> > > 20 files changed, 685 insertions(+), 7 deletions(-)
> > >
> > [...]
> >
> > > diff --git a/kernel/module/hashes_root.c b/kernel/module/hashes_root.c
> > > new file mode 100644
> > > index 000000000000..1abfcd3aa679
> > > --- /dev/null
> > > +++ b/kernel/module/hashes_root.c
> > > @@ -0,0 +1,6 @@
> > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > +
> > > +#include <linux/module_hashes.h>
> > > +
> > > +/* Blank dummy data. Will be overridden by link-vmlinux.sh */
> > > +const struct module_hashes_root module_hashes_root __module_hashes_section = {};
> > > diff --git a/kernel/module/internal.h b/kernel/module/internal.h
> > > index e2d49122c2a1..e22837d3ac76 100644
> > > --- a/kernel/module/internal.h
> > > +++ b/kernel/module/internal.h
> > > @@ -338,6 +338,7 @@ void module_mark_ro_after_init(const Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
> > > const char *secstrings);
> > >
> > > int module_sig_check(struct load_info *info, const u8 *sig, size_t sig_len);
> > > +int module_hash_check(struct load_info *info, const u8 *sig, size_t sig_len);
> > >
> > > #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 2a28a0ece809..fa30b6387936 100644
> > > --- a/kernel/module/main.c
> > > +++ b/kernel/module/main.c
> > > @@ -3362,8 +3362,10 @@ static int module_integrity_check(struct load_info *info, int flags)
> > >
> > > if (IS_ENABLED(CONFIG_MODULE_SIG) && sig_type == PKEY_ID_PKCS7) {
> > > err = module_sig_check(info, sig, sig_len);
> > > + } else if (IS_ENABLED(CONFIG_MODULE_HASHES) && sig_type == PKEY_ID_MERKLE) {
> > > + err = module_hash_check(info, sig, sig_len);
> > > } else {
> > > - pr_err("module: not signed with expected PKCS#7 message\n");
> > > + pr_err("module: not signed with signature mechanism\n");
> > > err = -ENOPKG;
> >
> > To prevent others from running into the same issue:
> >
> > My first test got stuck here, as I tested with virtme-ng, which symlinks
> > modules from build tree to /lib/modules/$(uname -r)/..., resulting in
> >
> > [ 15.956855] module: not signed with signature mechanism
> > modprobe: ERROR: could not insert 'efivarfs': Package not installed
> >
> > As the modules_install step was missing, modules were not being signed.
>
> Currently the signing is deferred to installation time to keep in sync
> with regular module signing and to keep the logic simpler by not having
> to gracefully handle previously-signed files.
> But this could be changed.
I did not want to suggest changing the behaviour, that would make things
more complicated to prevent needless rebuilds. I just wanted to mention
it here to prevent others from burning time.
> > [...]
> > > diff --git a/scripts/modules-merkle-tree.c b/scripts/modules-merkle-tree.c
> > > new file mode 100644
> > > index 000000000000..a6ec0e21213b
> > > --- /dev/null
> > > +++ b/scripts/modules-merkle-tree.c
> > > @@ -0,0 +1,467 @@
> > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > +/*
> > > + * Compute hashes for modules files and build a merkle tree.
> > > + *
> > > + * Copyright (C) 2025 Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
> > > + * Copyright (C) 2025 Thomas Weißschuh <linux@weissschuh.net>
> > > + *
> > > + */
> > > +#define _GNU_SOURCE 1
> > > +#include <arpa/inet.h>
> > > +#include <err.h>
> > > +#include <unistd.h>
> > > +#include <fcntl.h>
> > > +#include <stdarg.h>
> > > +#include <stdio.h>
> > > +#include <string.h>
> > > +#include <stdbool.h>
> > > +#include <stdlib.h>
> > > +
> > > +#include <sys/stat.h>
> > > +#include <sys/mman.h>
> > > +
> > > +#include <openssl/evp.h>
> > > +#include <openssl/err.h>
> > > +
> > > +#include "ssl-common.h"
> > > +
> > > +static int hash_size;
> > > +static EVP_MD_CTX *ctx;
> > > +
> > > +struct module_signature {
> > > + uint8_t algo; /* Public-key crypto algorithm [0] */
> > > + uint8_t hash; /* Digest algorithm [0] */
> > > + uint8_t id_type; /* Key identifier type [PKEY_ID_PKCS7] */
> > > + uint8_t signer_len; /* Length of signer's name [0] */
> > > + uint8_t key_id_len; /* Length of key identifier [0] */
> > > + uint8_t __pad[3];
> > > + uint32_t sig_len; /* Length of signature data */
> > > +};
> > > +
> > > +#define PKEY_ID_MERKLE 3
> > > +
> > > +static const char magic_number[] = "~Module signature appended~\n";
> >
> > This here will be the forth definition of struct module_signature,
> > increasing the risk of unwanted diversion. I second Petr's suggestion
> > to reuse a _common_ definition instead.
>
> Ack.
>
> > (Here, even include/linux/module_signature.h could be included itself.)
>
> I'd like to avoid including internal headers from other components.
> We could move it to an UAPI header. Various other subsystems use those
> for not-really-UAPI but still ABI definitions.
Yeah, ack.
> (...)
>
> > > +static inline char *xasprintf(const char *fmt, ...)
> > > +{
> > > + va_list ap;
> > > + char *strp;
> > > + int ret;
> > > +
> > > + va_start(ap, fmt);
> > > + ret = vasprintf(&strp, fmt, ap);
> > > + va_end(ap);
> > > + if (ret == -1)
> > > + err(1, "Memory allocation failed");
> > > +
> > > + return strp;
> > > +}
> >
> > Please consider moving these x* functions into scripts/include/xalloc.h
> > for reuse. (I am sure someone else wrote this already, but I can't find
> > it...)
>
> Petr suggested it somewhere, it is done for the next revision.
>
> > thanks for all your efforts for reproducibility!
> >
> > As I have no clue about that: Is the patent for merkle trees [1] a
> > problem when integrating that here?
>
> That should have expired a long time ago [2].
> And fs-verity is also using merkle trees.
Great, thanks.
> > Can you verify if I get the mechanics roughly correct?
> >
> > * Modules are merkle tree leaves. Modules are built and logically
> > paired by the order from modules.order; a single left-over module is
> > paired with itself.
> >
> > * Hashes of paired modules are hashed again (branch node hash);
> > hashes of pairs of branch nodes' hashes are hashed again;
> > repeat until we reach the single merkle tree root hash
> >
> > * The final merkle tree root hash (and the count of tree levels) is
> > included in vmlinux
>
> The merkle tree code was written by Sebastian so he will have the best
> knowledge about it. But this is also my understanding.
I'd like to see some (rough) description in Documentation or in a commit
message at least, otherwise future me will have to ask that again.
> > 'make && find . -name '*.ko' -exec rm {} \; && make' does not rebuild
> > the in-tree modules. Shifting the module-hashes support from
> > scripts/link-vmlinux.sh to scripts/Makefile.vmlinux might (make it
> > easier) to fix this again.
>
> I'll take a look at it.
Thanks!
Kind regards,
Nicolas
> > [1]: https://worldwide.espacenet.com/patent/search/family/022107098/publication/US4309569A?q=pn%3DUS4309569
>
> [2] https://patents.stackexchange.com/questions/17901/validity-of-patent-on-merkle-trees
>
>
> Thomas
--
Nicolas
^ permalink raw reply
* Re: [PATCH v4 15/17] module: Introduce hash-based integrity checking
From: Thomas Weißschuh @ 2026-02-23 7:53 UTC (permalink / raw)
To: Nicolas Schier
Cc: Nathan Chancellor, Arnd Bergmann, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, Daniel Gomez, Paul Moore, James Morris,
Serge E. Hallyn, Jonathan Corbet, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Naveen N Rao, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Daniel Gomez,
Aaron Tomlin, Christophe Leroy (CS GROUP), Nicolas Bouchinet,
Xiu Jianfeng, Fabian Grünbichler, Arnout Engelen,
Mattia Rizzolo, kpcyrd, Christian Heusel, Câju Mihai-Drosi,
Sebastian Andrzej Siewior, linux-kbuild, linux-kernel, linux-arch,
linux-modules, linux-security-module, linux-doc, linuxppc-dev,
linux-integrity
In-Reply-To: <aZol1Rsa2tX-WNaZ@derry.ads.avm.de>
On 2026-02-21 22:38:29+0100, Nicolas Schier wrote:
> On Tue, Jan 13, 2026 at 01:28:59PM +0100, 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 signing key is used, which precludes rebuilds by third parties
> > and makes the whole build and packaging process much more complicated.
> >
> > The goal is to reach bit-for-bit reproducibility. Excluding certain
> > parts of the build output from the reproducibility analysis would be
> > error-prone and force each downstream consumer to introduce new tooling.
> >
> > Introduce a new mechanism to ensure only well-known modules are loaded
> > by embedding a merkle tree root 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 build a merkle tree. This introduces a dependency cycle which is
> > impossible to satisfy. 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
> >
> > The PKCS7 format which is used for regular module signatures can not
> > represent Merkle proofs, so a new kind of module signature is
> > introduced. As this signature type is only ever used for builtin
> > modules, no compatibility issues can arise.
> >
> > 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 | 25 ++
> > include/linux/module_signature.h | 1 +
> > kernel/module/Kconfig | 21 +-
> > kernel/module/Makefile | 1 +
> > kernel/module/hashes.c | 92 ++++++
> > kernel/module/hashes_root.c | 6 +
> > kernel/module/internal.h | 1 +
> > kernel/module/main.c | 4 +-
> > scripts/.gitignore | 1 +
> > scripts/Makefile | 3 +
> > scripts/Makefile.modfinal | 11 +
> > scripts/Makefile.modinst | 13 +
> > scripts/Makefile.vmlinux | 5 +
> > scripts/link-vmlinux.sh | 14 +-
> > scripts/modules-merkle-tree.c | 467 +++++++++++++++++++++++++++
> > security/lockdown/Kconfig | 2 +-
> > 20 files changed, 685 insertions(+), 7 deletions(-)
> >
> [...]
>
> > diff --git a/kernel/module/hashes_root.c b/kernel/module/hashes_root.c
> > new file mode 100644
> > index 000000000000..1abfcd3aa679
> > --- /dev/null
> > +++ b/kernel/module/hashes_root.c
> > @@ -0,0 +1,6 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +
> > +#include <linux/module_hashes.h>
> > +
> > +/* Blank dummy data. Will be overridden by link-vmlinux.sh */
> > +const struct module_hashes_root module_hashes_root __module_hashes_section = {};
> > diff --git a/kernel/module/internal.h b/kernel/module/internal.h
> > index e2d49122c2a1..e22837d3ac76 100644
> > --- a/kernel/module/internal.h
> > +++ b/kernel/module/internal.h
> > @@ -338,6 +338,7 @@ void module_mark_ro_after_init(const Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
> > const char *secstrings);
> >
> > int module_sig_check(struct load_info *info, const u8 *sig, size_t sig_len);
> > +int module_hash_check(struct load_info *info, const u8 *sig, size_t sig_len);
> >
> > #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 2a28a0ece809..fa30b6387936 100644
> > --- a/kernel/module/main.c
> > +++ b/kernel/module/main.c
> > @@ -3362,8 +3362,10 @@ static int module_integrity_check(struct load_info *info, int flags)
> >
> > if (IS_ENABLED(CONFIG_MODULE_SIG) && sig_type == PKEY_ID_PKCS7) {
> > err = module_sig_check(info, sig, sig_len);
> > + } else if (IS_ENABLED(CONFIG_MODULE_HASHES) && sig_type == PKEY_ID_MERKLE) {
> > + err = module_hash_check(info, sig, sig_len);
> > } else {
> > - pr_err("module: not signed with expected PKCS#7 message\n");
> > + pr_err("module: not signed with signature mechanism\n");
> > err = -ENOPKG;
>
> To prevent others from running into the same issue:
>
> My first test got stuck here, as I tested with virtme-ng, which symlinks
> modules from build tree to /lib/modules/$(uname -r)/..., resulting in
>
> [ 15.956855] module: not signed with signature mechanism
> modprobe: ERROR: could not insert 'efivarfs': Package not installed
>
> As the modules_install step was missing, modules were not being signed.
Currently the signing is deferred to installation time to keep in sync
with regular module signing and to keep the logic simpler by not having
to gracefully handle previously-signed files.
But this could be changed.
> [...]
> > diff --git a/scripts/modules-merkle-tree.c b/scripts/modules-merkle-tree.c
> > new file mode 100644
> > index 000000000000..a6ec0e21213b
> > --- /dev/null
> > +++ b/scripts/modules-merkle-tree.c
> > @@ -0,0 +1,467 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Compute hashes for modules files and build a merkle tree.
> > + *
> > + * Copyright (C) 2025 Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
> > + * Copyright (C) 2025 Thomas Weißschuh <linux@weissschuh.net>
> > + *
> > + */
> > +#define _GNU_SOURCE 1
> > +#include <arpa/inet.h>
> > +#include <err.h>
> > +#include <unistd.h>
> > +#include <fcntl.h>
> > +#include <stdarg.h>
> > +#include <stdio.h>
> > +#include <string.h>
> > +#include <stdbool.h>
> > +#include <stdlib.h>
> > +
> > +#include <sys/stat.h>
> > +#include <sys/mman.h>
> > +
> > +#include <openssl/evp.h>
> > +#include <openssl/err.h>
> > +
> > +#include "ssl-common.h"
> > +
> > +static int hash_size;
> > +static EVP_MD_CTX *ctx;
> > +
> > +struct module_signature {
> > + uint8_t algo; /* Public-key crypto algorithm [0] */
> > + uint8_t hash; /* Digest algorithm [0] */
> > + uint8_t id_type; /* Key identifier type [PKEY_ID_PKCS7] */
> > + uint8_t signer_len; /* Length of signer's name [0] */
> > + uint8_t key_id_len; /* Length of key identifier [0] */
> > + uint8_t __pad[3];
> > + uint32_t sig_len; /* Length of signature data */
> > +};
> > +
> > +#define PKEY_ID_MERKLE 3
> > +
> > +static const char magic_number[] = "~Module signature appended~\n";
>
> This here will be the forth definition of struct module_signature,
> increasing the risk of unwanted diversion. I second Petr's suggestion
> to reuse a _common_ definition instead.
Ack.
> (Here, even include/linux/module_signature.h could be included itself.)
I'd like to avoid including internal headers from other components.
We could move it to an UAPI header. Various other subsystems use those
for not-really-UAPI but still ABI definitions.
(...)
> > +static inline char *xasprintf(const char *fmt, ...)
> > +{
> > + va_list ap;
> > + char *strp;
> > + int ret;
> > +
> > + va_start(ap, fmt);
> > + ret = vasprintf(&strp, fmt, ap);
> > + va_end(ap);
> > + if (ret == -1)
> > + err(1, "Memory allocation failed");
> > +
> > + return strp;
> > +}
>
> Please consider moving these x* functions into scripts/include/xalloc.h
> for reuse. (I am sure someone else wrote this already, but I can't find
> it...)
Petr suggested it somewhere, it is done for the next revision.
> thanks for all your efforts for reproducibility!
>
> As I have no clue about that: Is the patent for merkle trees [1] a
> problem when integrating that here?
That should have expired a long time ago [2].
And fs-verity is also using merkle trees.
> Can you verify if I get the mechanics roughly correct?
>
> * Modules are merkle tree leaves. Modules are built and logically
> paired by the order from modules.order; a single left-over module is
> paired with itself.
>
> * Hashes of paired modules are hashed again (branch node hash);
> hashes of pairs of branch nodes' hashes are hashed again;
> repeat until we reach the single merkle tree root hash
>
> * The final merkle tree root hash (and the count of tree levels) is
> included in vmlinux
The merkle tree code was written by Sebastian so he will have the best
knowledge about it. But this is also my understanding.
> 'make && find . -name '*.ko' -exec rm {} \; && make' does not rebuild
> the in-tree modules. Shifting the module-hashes support from
> scripts/link-vmlinux.sh to scripts/Makefile.vmlinux might (make it
> easier) to fix this again.
I'll take a look at it.
> [1]: https://worldwide.espacenet.com/patent/search/family/022107098/publication/US4309569A?q=pn%3DUS4309569
[2] https://patents.stackexchange.com/questions/17901/validity-of-patent-on-merkle-trees
Thomas
^ permalink raw reply
* Re: [PATCH v18 31/42] dept: assign unique dept_key to each distinct wait_for_completion() caller
From: Byungchul Park @ 2026-02-23 0:32 UTC (permalink / raw)
To: Dirk Behme
Cc: linux-kernel, kernel_team, torvalds, damien.lemoal, linux-ide,
adilger.kernel, linux-ext4, mingo, peterz, will, tglx, rostedt,
joel, sashal, daniel.vetter, duyuyang, johannes.berg, tj, tytso,
willy, david, amir73il, gregkh, kernel-team, linux-mm, akpm,
mhocko, minchan, hannes, vdavydov.dev, sj, jglisse, dennis, cl,
penberg, rientjes, vbabka, ngupta, linux-block, josef,
linux-fsdevel, jack, jlayton, dan.j.williams, hch, djwong,
dri-devel, rodrigosiqueiramelo, melissa.srw, hamohammed.sa,
harry.yoo, chris.p.wilson, gwan-gyeong.mun, max.byungchul.park,
boqun.feng, longman, yunseong.kim, ysk, yeoreum.yun, netdev,
matthew.brost, her0gyugyu, corbet, catalin.marinas, bp, x86, hpa,
luto, sumit.semwal, gustavo, christian.koenig, andi.shyti, arnd,
lorenzo.stoakes, Liam.Howlett, rppt, surenb, mcgrof, petr.pavlu,
da.gomez, samitolvanen, paulmck, frederic, neeraj.upadhyay,
joelagnelf, josh, urezki, mathieu.desnoyers, jiangshanlai,
qiang.zhang, juri.lelli, vincent.guittot, dietmar.eggemann,
bsegall, mgorman, vschneid, chuck.lever, neil, okorniev, Dai.Ngo,
tom, trondmy, anna, kees, bigeasy, clrkwllms, mark.rutland,
ada.coupriediaz, kristina.martsenko, wangkefeng.wang, broonie,
kevin.brodsky, dwmw, shakeel.butt, ast, ziy, yuzhao, baolin.wang,
usamaarif642, joel.granados, richard.weiyang, geert+renesas,
tim.c.chen, linux, alexander.shishkin, lillian, chenhuacai,
francesco, guoweikang.kernel, link, jpoimboe, masahiroy, brauner,
thomas.weissschuh, oleg, mjguzik, andrii, wangfushuai, linux-doc,
linux-arm-kernel, linux-media, linaro-mm-sig, linux-i2c,
linux-arch, linux-modules, rcu, linux-nfs, linux-rt-devel,
2407018371, dakr, miguel.ojeda.sandonis, neilb, bagasdotme,
wsa+renesas, dave.hansen, geert, ojeda, alex.gaynor, gary,
bjorn3_gh, lossin, a.hindborg, aliceryhl, tmgross, rust-for-linux
In-Reply-To: <ab0b9f9c-3a05-42f3-b4a7-ddb6ab0d37a4@gmx.de>
On Sun, Feb 15, 2026 at 07:42:05AM +0100, Dirk Behme wrote:
> On 05.12.25 08:18, Byungchul Park wrote:
> > wait_for_completion() can be used at various points in the code and it's
> > very hard to distinguish wait_for_completion()s between different usages.
> > Using a single dept_key for all the wait_for_completion()s could trigger
> > false positive reports.
> >
> > Assign unique dept_key to each distinct wait_for_completion() caller to
> > avoid false positive reports.
> >
> > While at it, add a rust helper for wait_for_completion() to avoid build
> > errors.
> >
> > Signed-off-by: Byungchul Park <byungchul@sk.com>
> > ---
> > include/linux/completion.h | 100 +++++++++++++++++++++++++++++++------
> > kernel/sched/completion.c | 60 +++++++++++-----------
> > rust/helpers/completion.c | 5 ++
> > 3 files changed, 120 insertions(+), 45 deletions(-)
> >
> ...
> > diff --git a/rust/helpers/completion.c b/rust/helpers/completion.c
> > index b2443262a2ae..5bae5e749def 100644
> > --- a/rust/helpers/completion.c
> > +++ b/rust/helpers/completion.c
> > @@ -6,3 +6,8 @@ void rust_helper_init_completion(struct completion *x)
> > {
> > init_completion(x);
> > }
> > +
> > +void rust_helper_wait_for_completion(struct completion *x)
>
> Please add `__rust_helper`:
I will. Thanks.
Byungchul
>
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/rust/helpers/completion.c?h=next-20260213&id=1c7a6f48f7eeb3014584d2fc55fc67f0cbaeef69
>
> Best regards
>
> Dirk
^ permalink raw reply
* Re: [PATCH v18 34/42] dept: add module support for struct dept_event_site and dept_event_site_dep
From: Byungchul Park @ 2026-02-23 0:33 UTC (permalink / raw)
To: Petr Pavlu
Cc: kernel_team, torvalds, damien.lemoal, linux-ide, adilger.kernel,
linux-ext4, mingo, peterz, will, tglx, rostedt, joel, sashal,
daniel.vetter, duyuyang, johannes.berg, tj, tytso, willy, david,
amir73il, gregkh, kernel-team, linux-mm, akpm, mhocko, minchan,
hannes, vdavydov.dev, sj, jglisse, dennis, cl, penberg, rientjes,
vbabka, ngupta, linux-block, josef, linux-fsdevel, jack, jlayton,
dan.j.williams, hch, djwong, dri-devel, rodrigosiqueiramelo,
melissa.srw, hamohammed.sa, harry.yoo, chris.p.wilson,
gwan-gyeong.mun, max.byungchul.park, boqun.feng, longman,
yunseong.kim, ysk, yeoreum.yun, netdev, matthew.brost, her0gyugyu,
corbet, catalin.marinas, bp, x86, hpa, luto, sumit.semwal,
gustavo, christian.koenig, andi.shyti, arnd, lorenzo.stoakes,
Liam.Howlett, rppt, surenb, mcgrof, da.gomez, samitolvanen,
paulmck, frederic, neeraj.upadhyay, joelagnelf, josh, urezki,
mathieu.desnoyers, jiangshanlai, qiang.zhang, juri.lelli,
vincent.guittot, dietmar.eggemann, bsegall, mgorman, vschneid,
chuck.lever, neil, okorniev, Dai.Ngo, tom, trondmy, anna, kees,
bigeasy, clrkwllms, mark.rutland, ada.coupriediaz,
kristina.martsenko, wangkefeng.wang, broonie, kevin.brodsky, dwmw,
shakeel.butt, ast, ziy, yuzhao, baolin.wang, usamaarif642,
joel.granados, richard.weiyang, geert+renesas, tim.c.chen, linux,
alexander.shishkin, lillian, chenhuacai, francesco,
guoweikang.kernel, link, jpoimboe, masahiroy, brauner,
thomas.weissschuh, oleg, mjguzik, andrii, wangfushuai, linux-doc,
linux-arm-kernel, linux-media, linaro-mm-sig, linux-i2c,
linux-arch, linux-modules, rcu, linux-nfs, linux-rt-devel,
2407018371, dakr, miguel.ojeda.sandonis, neilb, bagasdotme,
wsa+renesas, dave.hansen, geert, ojeda, alex.gaynor, gary,
bjorn3_gh, lossin, a.hindborg, aliceryhl, tmgross, rust-for-linux,
linux-kernel
In-Reply-To: <7765df86-b08a-4f70-900d-4b4d85c07d49@suse.com>
On Wed, Feb 18, 2026 at 04:08:19PM +0100, Petr Pavlu wrote:
> On 2/13/26 6:50 AM, Byungchul Park wrote:
> > On Wed, Jan 07, 2026 at 01:19:00PM +0100, Petr Pavlu wrote:
> >> On 12/5/25 8:18 AM, Byungchul Park wrote:
> >>> struct dept_event_site and struct dept_event_site_dep have been
> >>> introduced to track dependencies between multi event sites for a single
> >>> wait, that will be loaded to data segment. Plus, a custom section,
> >>> '.dept.event_sites', also has been introduced to keep pointers to the
> >>> objects to make sure all the event sites defined exist in code.
> >>>
> >>> dept should work with the section and segment of module. Add the
> >>> support to handle the section and segment properly whenever modules are
> >>> loaded and unloaded.
> >>>
> >>> Signed-off-by: Byungchul Park <byungchul@sk.com>
> >>
> >> Below are a few comments from the module loader perspective.
> >
> > Sorry about the late reply. I've been going through some major life
> > changes lately. :(
> >
> > Thank you sooooo~ much for your helpful feedback. I will leave my
> > opinion below.
> >
> [...]
> >>> diff --git a/kernel/dependency/dept.c b/kernel/dependency/dept.c
> >>> index b14400c4f83b..07d883579269 100644
> >>> --- a/kernel/dependency/dept.c
> >>> +++ b/kernel/dependency/dept.c
> >>> @@ -984,6 +984,9 @@ static void bfs(void *root, struct bfs_ops *ops, void *in, void **out)
> >>> * event sites.
> >>> */
> >>>
> >>> +static LIST_HEAD(dept_event_sites);
> >>> +static LIST_HEAD(dept_event_site_deps);
> >>> +
> >>> /*
> >>> * Print all events in the circle.
> >>> */
> >>> @@ -2043,6 +2046,33 @@ static void del_dep_rcu(struct rcu_head *rh)
> >>> preempt_enable();
> >>> }
> >>>
> >>> +/*
> >>> + * NOTE: Must be called with dept_lock held.
> >>> + */
> >>> +static void disconnect_event_site_dep(struct dept_event_site_dep *esd)
> >>> +{
> >>> + list_del_rcu(&esd->dep_node);
> >>> + list_del_rcu(&esd->dep_rev_node);
> >>> +}
> >>> +
> >>> +/*
> >>> + * NOTE: Must be called with dept_lock held.
> >>> + */
> >>> +static void disconnect_event_site(struct dept_event_site *es)
> >>> +{
> >>> + struct dept_event_site_dep *esd, *next_esd;
> >>> +
> >>> + list_for_each_entry_safe(esd, next_esd, &es->dep_head, dep_node) {
> >>> + list_del_rcu(&esd->dep_node);
> >>> + list_del_rcu(&esd->dep_rev_node);
> >>> + }
> >>> +
> >>> + list_for_each_entry_safe(esd, next_esd, &es->dep_rev_head, dep_rev_node) {
> >>> + list_del_rcu(&esd->dep_node);
> >>> + list_del_rcu(&esd->dep_rev_node);
> >>> + }
> >>> +}
> >>> +
> >>> /*
> >>> * NOTE: Must be called with dept_lock held.
> >>> */
> >>> @@ -2384,6 +2414,8 @@ void dept_free_range(void *start, unsigned int sz)
> >>> {
> >>> struct dept_task *dt = dept_task();
> >>> struct dept_class *c, *n;
> >>> + struct dept_event_site_dep *esd, *next_esd;
> >>> + struct dept_event_site *es, *next_es;
> >>> unsigned long flags;
> >>>
> >>> if (unlikely(!dept_working()))
> >>> @@ -2405,6 +2437,24 @@ void dept_free_range(void *start, unsigned int sz)
> >>> while (unlikely(!dept_lock()))
> >>> cpu_relax();
> >>>
> >>> + list_for_each_entry_safe(esd, next_esd, &dept_event_site_deps, all_node) {
> >>> + if (!within((void *)esd, start, sz))
> >>> + continue;
> >>> +
> >>> + disconnect_event_site_dep(esd);
> >>> + list_del(&esd->all_node);
> >>> + }
> >>> +
> >>> + list_for_each_entry_safe(es, next_es, &dept_event_sites, all_node) {
> >>> + if (!within((void *)es, start, sz) &&
> >>> + !within(es->name, start, sz) &&
> >>> + !within(es->func_name, start, sz))
> >>> + continue;
> >>> +
> >>> + disconnect_event_site(es);
> >>> + list_del(&es->all_node);
> >>> + }
> >>> +
> >>> list_for_each_entry_safe(c, n, &dept_classes, all_node) {
> >>> if (!within((void *)c->key, start, sz) &&
> >>> !within(c->name, start, sz))
> >>> @@ -3337,6 +3387,7 @@ void __dept_recover_event(struct dept_event_site_dep *esd,
> >>>
> >>> list_add(&esd->dep_node, &es->dep_head);
> >>> list_add(&esd->dep_rev_node, &rs->dep_rev_head);
> >>> + list_add(&esd->all_node, &dept_event_site_deps);
> >>> check_recover_dl_bfs(esd);
> >>> unlock:
> >>> dept_unlock();
> >>> @@ -3347,6 +3398,23 @@ EXPORT_SYMBOL_GPL(__dept_recover_event);
> >>>
> >>> #define B2KB(B) ((B) / 1024)
> >>>
> >>> +void dept_mark_event_site_used(void *start, void *end)
> >>
> >> Nit: I suggest that dept_mark_event_site_used() take pointers to
> >> dept_event_site_init, which would catch the type mismatch with
> >
> > IMO, this is the easiest way to get all the pointers from start to the
> > end, or I can't get the number of the pointers. It's similar to the
> > initcalls section for device drivers.
>
> This was a minor suggestion.. The idea is to simply change the function
> signature to:
>
> void dept_mark_event_site_used(struct dept_event_site_init **start,
> struct dept_event_site_init **end))
I got what you meant. I will. Thanks.
Byungchul
> This way, the compiler can provide proper type checking to ensure that
> correct pointers are passed to dept_mark_event_site_used(). It would
> catch the type mismatch with module::dept_event_sites.
>
> >
> >> module::dept_event_sites.
> >>
> >>> +{
> >>> + struct dept_event_site_init **evtinitpp;
> >>> +
> >>> + for (evtinitpp = (struct dept_event_site_init **)start;
> >>> + evtinitpp < (struct dept_event_site_init **)end;
> >>> + evtinitpp++) {
> >>> + (*evtinitpp)->evt_site->used = true;
> >>> + (*evtinitpp)->evt_site->func_name = (*evtinitpp)->func_name;
> >>> + list_add(&(*evtinitpp)->evt_site->all_node, &dept_event_sites);
> >>> +
> >>> + pr_info("dept_event_site %s@%s is initialized.\n",
> >>> + (*evtinitpp)->evt_site->name,
> >>> + (*evtinitpp)->evt_site->func_name);
> >>> + }
> >>> +}
> >>> +
> >>> extern char __dept_event_sites_start[], __dept_event_sites_end[];
> >>
> >> Related to the above, __dept_event_sites_start and
> >> __dept_event_sites_end can already be properly typed here.
> >
> > How can I get the number of the pointers?
>
> Similarly here, changing the code to:
>
> extern struct dept_event_site_init *__dept_event_sites_start[], *__dept_event_sites_end[];
>
> It is the same for the initcalls you mentioned. The declarations of
> their start/end symbols are also already properly typed as
> initcall_entry_t[] in include/linux/init.h.
>
> --
> Thanks,
> Petr
^ permalink raw reply
* Re: [PATCH v4 15/17] module: Introduce hash-based integrity checking
From: Nicolas Schier @ 2026-02-21 21:38 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Nathan Chancellor, Arnd Bergmann, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, Daniel Gomez, Paul Moore, James Morris,
Serge E. Hallyn, Jonathan Corbet, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Naveen N Rao, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Daniel Gomez,
Aaron Tomlin, Christophe Leroy (CS GROUP), Nicolas Bouchinet,
Xiu Jianfeng, Fabian Grünbichler, Arnout Engelen,
Mattia Rizzolo, kpcyrd, Christian Heusel, Câju Mihai-Drosi,
Sebastian Andrzej Siewior, linux-kbuild, linux-kernel, linux-arch,
linux-modules, linux-security-module, linux-doc, linuxppc-dev,
linux-integrity
In-Reply-To: <20260113-module-hashes-v4-15-0b932db9b56b@weissschuh.net>
Hi Thomas,
On Tue, Jan 13, 2026 at 01:28:59PM +0100, 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 signing key is used, which precludes rebuilds by third parties
> and makes the whole build and packaging process much more complicated.
>
> The goal is to reach bit-for-bit reproducibility. Excluding certain
> parts of the build output from the reproducibility analysis would be
> error-prone and force each downstream consumer to introduce new tooling.
>
> Introduce a new mechanism to ensure only well-known modules are loaded
> by embedding a merkle tree root 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 build a merkle tree. This introduces a dependency cycle which is
> impossible to satisfy. 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
>
> The PKCS7 format which is used for regular module signatures can not
> represent Merkle proofs, so a new kind of module signature is
> introduced. As this signature type is only ever used for builtin
> modules, no compatibility issues can arise.
>
> 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 | 25 ++
> include/linux/module_signature.h | 1 +
> kernel/module/Kconfig | 21 +-
> kernel/module/Makefile | 1 +
> kernel/module/hashes.c | 92 ++++++
> kernel/module/hashes_root.c | 6 +
> kernel/module/internal.h | 1 +
> kernel/module/main.c | 4 +-
> scripts/.gitignore | 1 +
> scripts/Makefile | 3 +
> scripts/Makefile.modfinal | 11 +
> scripts/Makefile.modinst | 13 +
> scripts/Makefile.vmlinux | 5 +
> scripts/link-vmlinux.sh | 14 +-
> scripts/modules-merkle-tree.c | 467 +++++++++++++++++++++++++++
> security/lockdown/Kconfig | 2 +-
> 20 files changed, 685 insertions(+), 7 deletions(-)
>
[...]
> diff --git a/kernel/module/hashes_root.c b/kernel/module/hashes_root.c
> new file mode 100644
> index 000000000000..1abfcd3aa679
> --- /dev/null
> +++ b/kernel/module/hashes_root.c
> @@ -0,0 +1,6 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +
> +#include <linux/module_hashes.h>
> +
> +/* Blank dummy data. Will be overridden by link-vmlinux.sh */
> +const struct module_hashes_root module_hashes_root __module_hashes_section = {};
> diff --git a/kernel/module/internal.h b/kernel/module/internal.h
> index e2d49122c2a1..e22837d3ac76 100644
> --- a/kernel/module/internal.h
> +++ b/kernel/module/internal.h
> @@ -338,6 +338,7 @@ void module_mark_ro_after_init(const Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
> const char *secstrings);
>
> int module_sig_check(struct load_info *info, const u8 *sig, size_t sig_len);
> +int module_hash_check(struct load_info *info, const u8 *sig, size_t sig_len);
>
> #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 2a28a0ece809..fa30b6387936 100644
> --- a/kernel/module/main.c
> +++ b/kernel/module/main.c
> @@ -3362,8 +3362,10 @@ static int module_integrity_check(struct load_info *info, int flags)
>
> if (IS_ENABLED(CONFIG_MODULE_SIG) && sig_type == PKEY_ID_PKCS7) {
> err = module_sig_check(info, sig, sig_len);
> + } else if (IS_ENABLED(CONFIG_MODULE_HASHES) && sig_type == PKEY_ID_MERKLE) {
> + err = module_hash_check(info, sig, sig_len);
> } else {
> - pr_err("module: not signed with expected PKCS#7 message\n");
> + pr_err("module: not signed with signature mechanism\n");
> err = -ENOPKG;
To prevent others from running into the same issue:
My first test got stuck here, as I tested with virtme-ng, which symlinks
modules from build tree to /lib/modules/$(uname -r)/..., resulting in
[ 15.956855] module: not signed with signature mechanism
modprobe: ERROR: could not insert 'efivarfs': Package not installed
As the modules_install step was missing, modules were not being signed.
[...]
> diff --git a/scripts/modules-merkle-tree.c b/scripts/modules-merkle-tree.c
> new file mode 100644
> index 000000000000..a6ec0e21213b
> --- /dev/null
> +++ b/scripts/modules-merkle-tree.c
> @@ -0,0 +1,467 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Compute hashes for modules files and build a merkle tree.
> + *
> + * Copyright (C) 2025 Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
> + * Copyright (C) 2025 Thomas Weißschuh <linux@weissschuh.net>
> + *
> + */
> +#define _GNU_SOURCE 1
> +#include <arpa/inet.h>
> +#include <err.h>
> +#include <unistd.h>
> +#include <fcntl.h>
> +#include <stdarg.h>
> +#include <stdio.h>
> +#include <string.h>
> +#include <stdbool.h>
> +#include <stdlib.h>
> +
> +#include <sys/stat.h>
> +#include <sys/mman.h>
> +
> +#include <openssl/evp.h>
> +#include <openssl/err.h>
> +
> +#include "ssl-common.h"
> +
> +static int hash_size;
> +static EVP_MD_CTX *ctx;
> +
> +struct module_signature {
> + uint8_t algo; /* Public-key crypto algorithm [0] */
> + uint8_t hash; /* Digest algorithm [0] */
> + uint8_t id_type; /* Key identifier type [PKEY_ID_PKCS7] */
> + uint8_t signer_len; /* Length of signer's name [0] */
> + uint8_t key_id_len; /* Length of key identifier [0] */
> + uint8_t __pad[3];
> + uint32_t sig_len; /* Length of signature data */
> +};
> +
> +#define PKEY_ID_MERKLE 3
> +
> +static const char magic_number[] = "~Module signature appended~\n";
This here will be the forth definition of struct module_signature,
increasing the risk of unwanted diversion. I second Petr's suggestion
to reuse a _common_ definition instead.
(Here, even include/linux/module_signature.h could be included itself.)
> +
> +struct file_entry {
> + char *name;
> + unsigned int pos;
> + unsigned char hash[EVP_MAX_MD_SIZE];
> +};
> +
> +static struct file_entry *fh_list;
> +static size_t num_files;
> +
> +struct leaf_hash {
> + unsigned char hash[EVP_MAX_MD_SIZE];
> +};
> +
> +struct mtree {
> + struct leaf_hash **l;
> + unsigned int *entries;
> + unsigned int levels;
> +};
> +
> +static inline void *xcalloc(size_t n, size_t size)
> +{
> + void *p;
> +
> + p = calloc(n, size);
> + if (!p)
> + errx(1, "Memory allocation failed");
> +
> + return p;
> +}
> +
> +static void *xmalloc(size_t size)
> +{
> + void *p;
> +
> + p = malloc(size);
> + if (!p)
> + errx(1, "Memory allocation failed");
> +
> + return p;
> +}
> +
> +static inline void *xreallocarray(void *oldp, size_t n, size_t size)
> +{
> + void *p;
> +
> + p = reallocarray(oldp, n, size);
> + if (!p)
> + errx(1, "Memory allocation failed");
> +
> + return p;
> +}
> +
> +static inline char *xasprintf(const char *fmt, ...)
> +{
> + va_list ap;
> + char *strp;
> + int ret;
> +
> + va_start(ap, fmt);
> + ret = vasprintf(&strp, fmt, ap);
> + va_end(ap);
> + if (ret == -1)
> + err(1, "Memory allocation failed");
> +
> + return strp;
> +}
Please consider moving these x* functions into scripts/include/xalloc.h
for reuse. (I am sure someone else wrote this already, but I can't find
it...)
>
>
thanks for all your efforts for reproducibility!
As I have no clue about that: Is the patent for merkle trees [1] a
problem when integrating that here?
Can you verify if I get the mechanics roughly correct?
* Modules are merkle tree leaves. Modules are built and logically
paired by the order from modules.order; a single left-over module is
paired with itself.
* Hashes of paired modules are hashed again (branch node hash);
hashes of pairs of branch nodes' hashes are hashed again;
repeat until we reach the single merkle tree root hash
* The final merkle tree root hash (and the count of tree levels) is
included in vmlinux
'make && find . -name '*.ko' -exec rm {} \; && make' does not rebuild
the in-tree modules. Shifting the module-hashes support from
scripts/link-vmlinux.sh to scripts/Makefile.vmlinux might (make it
easier) to fix this again.
Kind regards,
Nicolas
[1]: https://worldwide.espacenet.com/patent/search/family/022107098/publication/US4309569A?q=pn%3DUS4309569
--
Nicolas
^ permalink raw reply
* Re: [PATCH] builtin: mark __builtin_strlen() as integer constant expression
From: Chris Li @ 2026-02-20 19:34 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Daniel Gomez, Al Viro, Sami Tolvanen, linux-sparse, Aaron Tomlin,
Dan Carpenter, Dmitry Torokhov, Eric Biggers, linux-kernel,
linux-modules, Luck, Tony, Luis Chamberlain, Petr Pavlu
In-Reply-To: <aZgbw40qk2zIRpbE@smile.fi.intel.com>
On Fri, Feb 20, 2026 at 12:31 AM Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> On Fri, Feb 20, 2026 at 12:06:15AM -0800, Chris Li wrote:
> > On Thu, Feb 19, 2026 at 11:20 AM Andy Shevchenko
> > <andriy.shevchenko@intel.com> wrote:
> > >
> > > On Thu, Feb 19, 2026 at 09:06:23AM -0800, Chris Li wrote:
> > > > On Thu, Feb 19, 2026 at 9:00 AM Daniel Gomez <da.gomez@kernel.org> wrote:
> > > > >
> > > > > Can you please take a look? If Al patch is the correct approach, any
> > > > > chance you can send it and fix this?
> > > >
> > > > I am asking in another thread should I pull Al's git repo instead.
> > > > There are a few good commits there.
> > >
> > > Please, pull Al's work, My colleagues and I use his version of sparse for a few
> > > weeks without noticing any downsides.
> >
> > Thanks for the heads up. I just pulled Al's sparse repo.
>
> Can you also issue a new tag (say 0.6.5) so the distros can really be pushed to
> update the quite outdated sparse in their repos?
Sure. I can give it a spin this weekend and keep you posted. There is
one risk on my signing key, it might be expired and I need to sort
that out.
Meanwhile, please give the current sparse repo some good tests.
Chris
^ permalink raw reply
* Re: [PATCH] module: Fix the modversions and signing submenus
From: Daniel Gomez @ 2026-02-20 15:55 UTC (permalink / raw)
To: Petr Pavlu
Cc: Luis Chamberlain, Sami Tolvanen, Aaron Tomlin, linux-modules,
linux-kernel
In-Reply-To: <20260205143720.423026-1-petr.pavlu@suse.com>
On 2026-02-05 15:37, Petr Pavlu wrote:
> The module Kconfig file contains a set of options related to "Module
> versioning support" (depends on MODVERSIONS) and "Module signature
> verification" (depends on MODULE_SIG). The Kconfig tool automatically
> creates submenus when an entry for a symbol is followed by consecutive
> items that all depend on the symbol. However, this functionality doesn't
> work for the mentioned module options. The MODVERSIONS options are
> interleaved with ASM_MODVERSIONS, which has no 'depends on MODVERSIONS' but
> instead uses 'default HAVE_ASM_MODVERSIONS && MODVERSIONS'. Similarly, the
> MODULE_SIG options are interleaved by a comment warning not to forget
> signing modules with scripts/sign-file, which uses the condition 'depends
> on MODULE_SIG_FORCE && !MODULE_SIG_ALL'.
>
> The result is that the options are confusingly shown when using
> a menuconfig tool, as follows:
>
> [*] Module versioning support
> Module versioning implementation (genksyms (from source code)) --->
> [ ] Extended Module Versioning Support
> [*] Basic Module Versioning Support
> [*] Source checksum for all modules
> [*] Module signature verification
> [ ] Require modules to be validly signed
> [ ] Automatically sign all modules
> Hash algorithm to sign modules (SHA-256) --->
>
> Fix the issue by using if/endif to group related options together in
> kernel/module/Kconfig, similarly to how the MODULE_DEBUG options are
> already grouped. Note that the signing-related options depend on
> 'MODULE_SIG || IMA_APPRAISE_MODSIG', with the exception of
> MODULE_SIG_FORCE, which is valid only for MODULE_SIG and is therefore kept
> separately. For consistency, do the same for the MODULE_COMPRESS entries.
> The options are then properly placed into submenus, as follows:
>
> [*] Module versioning support
> Module versioning implementation (genksyms (from source code)) --->
> [ ] Extended Module Versioning Support
> [*] Basic Module Versioning Support
> [*] Source checksum for all modules
> [*] Module signature verification
> [ ] Require modules to be validly signed
> [ ] Automatically sign all modules
> Hash algorithm to sign modules (SHA-256) --->
>
> Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
Reviewed-by: Daniel Gomez <da.gomez@samsung.com>
^ permalink raw reply
* Re: [PATCH] module: Remove duplicate freeing of lockdep classes
From: Daniel Gomez @ 2026-02-20 15:55 UTC (permalink / raw)
To: Petr Pavlu
Cc: Luis Chamberlain, Sami Tolvanen, Aaron Tomlin, Peter Zijlstra,
Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, Song Liu,
linux-modules, linux-kernel
In-Reply-To: <20260107122329.1324707-1-petr.pavlu@suse.com>
On 2026-01-07 13:22, Petr Pavlu wrote:
> In the error path of load_module(), under the free_module label, the
> code calls lockdep_free_key_range() to release lock classes associated
> with the MOD_DATA, MOD_RODATA and MOD_RO_AFTER_INIT module regions, and
> subsequently invokes module_deallocate().
>
> Since commit ac3b43283923 ("module: replace module_layout with
> module_memory"), the module_deallocate() function calls free_mod_mem(),
> which releases the lock classes as well and considers all module
> regions.
>
> Attempting to free these classes twice is unnecessary. Remove the
> redundant code in load_module().
I'd even say module_deallocate() handles MOD_DATA properly (deferring
it to the last one) while the first loop was not taking that into
consideration.
>
> Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
Reviewed-by: Daniel Gomez <da.gomez@samsung.com>
^ permalink raw reply
* Re: [PATCH] module: Fix kernel panic when a symbol st_shndx is out of bounds
From: Daniel Gomez @ 2026-02-20 15:55 UTC (permalink / raw)
To: Ihor Solodrai
Cc: Luis Chamberlain, Petr Pavlu, Nathan Chancellor,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, linux-kernel, linux-modules,
bpf, linux-kbuild, llvm
In-Reply-To: <20251230183208.1317279-1-ihor.solodrai@linux.dev>
On 2025-12-30 10:32, Ihor Solodrai wrote:
> The module loader doesn't check for bounds of the ELF section index in
> simplify_symbols():
>
> for (i = 1; i < symsec->sh_size / sizeof(Elf_Sym); i++) {
> const char *name = info->strtab + sym[i].st_name;
>
> switch (sym[i].st_shndx) {
> case SHN_COMMON:
>
> [...]
>
> default:
> /* Divert to percpu allocation if a percpu var. */
> if (sym[i].st_shndx == info->index.pcpu)
> secbase = (unsigned long)mod_percpu(mod);
> else
> /** HERE --> **/ secbase = info->sechdrs[sym[i].st_shndx].sh_addr;
> sym[i].st_value += secbase;
> break;
> }
> }
>
> A symbol with an out-of-bounds st_shndx value, for example 0xffff
> (known as SHN_XINDEX or SHN_HIRESERVE), may cause a kernel panic:
>
> BUG: unable to handle page fault for address: ...
> RIP: 0010:simplify_symbols+0x2b2/0x480
> ...
> Kernel panic - not syncing: Fatal exception
>
> This can happen when module ELF is legitimately using SHN_XINDEX or
> when it is corrupted.
>
> Add a bounds check in simplify_symbols() to validate that st_shndx is
> within the valid range before using it.
>
> This issue was discovered due to a bug in llvm-objcopy, see relevant
> discussion for details [1].
>
> [1] https://lore.kernel.org/linux-modules/20251224005752.201911-1-ihor.solodrai@linux.dev/
>
> Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
Reviewed-by: Daniel Gomez <da.gomez@samsung.com>
^ permalink raw reply
* Re: [PATCH] builtin: mark __builtin_strlen() as integer constant expression
From: Andy Shevchenko @ 2026-02-20 8:30 UTC (permalink / raw)
To: Chris Li
Cc: Daniel Gomez, Al Viro, Sami Tolvanen, linux-sparse, Aaron Tomlin,
Dan Carpenter, Dmitry Torokhov, Eric Biggers, linux-kernel,
linux-modules, Luck, Tony, Luis Chamberlain, Petr Pavlu
In-Reply-To: <CACePvbWpC7o-Du=pr4Cfn-pM_XcOM1v+6cHb5mqaaEvzsvMX=Q@mail.gmail.com>
On Fri, Feb 20, 2026 at 12:06:15AM -0800, Chris Li wrote:
> On Thu, Feb 19, 2026 at 11:20 AM Andy Shevchenko
> <andriy.shevchenko@intel.com> wrote:
> >
> > On Thu, Feb 19, 2026 at 09:06:23AM -0800, Chris Li wrote:
> > > On Thu, Feb 19, 2026 at 9:00 AM Daniel Gomez <da.gomez@kernel.org> wrote:
> > > >
> > > > Can you please take a look? If Al patch is the correct approach, any
> > > > chance you can send it and fix this?
> > >
> > > I am asking in another thread should I pull Al's git repo instead.
> > > There are a few good commits there.
> >
> > Please, pull Al's work, My colleagues and I use his version of sparse for a few
> > weeks without noticing any downsides.
>
> Thanks for the heads up. I just pulled Al's sparse repo.
Can you also issue a new tag (say 0.6.5) so the distros can really be pushed to
update the quite outdated sparse in their repos?
> Sorry for the delay.
Thanks!
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] builtin: mark __builtin_strlen() as integer constant expression
From: Chris Li @ 2026-02-20 8:06 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Daniel Gomez, Al Viro, Sami Tolvanen, linux-sparse, Aaron Tomlin,
Dan Carpenter, Dmitry Torokhov, Eric Biggers, linux-kernel,
linux-modules, Luck, Tony, Luis Chamberlain, Petr Pavlu
In-Reply-To: <aZdighmTJN-JaijL@smile.fi.intel.com>
On Thu, Feb 19, 2026 at 11:20 AM Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> On Thu, Feb 19, 2026 at 09:06:23AM -0800, Chris Li wrote:
> > On Thu, Feb 19, 2026 at 9:00 AM Daniel Gomez <da.gomez@kernel.org> wrote:
> > >
> > > Can you please take a look? If Al patch is the correct approach, any
> > > chance you can send it and fix this?
> >
> > I am asking in another thread should I pull Al's git repo instead.
> > There are a few good commits there.
>
> Please, pull Al's work, My colleagues and I use his version of sparse for a few
> weeks without noticing any downsides.
Thanks for the heads up. I just pulled Al's sparse repo.
Sorry for the delay.
Chris
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox