* Re: [PATCH v2] lsm,ima: new LSM hook security_kernel_module_read_file to access decompressed kernel module
From: Coiby Xu @ 2025-11-13 4:06 UTC (permalink / raw)
To: Mimi Zohar
Cc: Paul Moore, linux-integrity, linux-security-module, Karel Srot,
James Morris, Serge E. Hallyn, Luis Chamberlain, Petr Pavlu,
Daniel Gomez, Sami Tolvanen, Roberto Sassu, Dmitry Kasatkin,
Eric Snowberg, open list, open list:MODULE SUPPORT
In-Reply-To: <0dfec96bf98b1c18d51bf40f4329c3ede48a9f32.camel@linux.ibm.com>
On Fri, Nov 07, 2025 at 02:28:13PM -0500, Mimi Zohar wrote:
>On Thu, 2025-11-06 at 17:15 -0500, Mimi Zohar wrote:
>> On Thu, 2025-11-06 at 21:29 +0800, Coiby Xu wrote:
>> > On Wed, Nov 05, 2025 at 03:47:25PM -0500, Mimi Zohar wrote:
>> > > On Wed, 2025-11-05 at 08:18 +0800, Coiby Xu wrote:
>> > [...]
>> > >
>> > > Hi Coiby,
>> > >
>> > > Based on the conversation with Paul, there is no reason to remove the existing
>> > > security_kernel_post_read_file() call.
>> > >
>> > > The changes are similar to the 2nd link, but a bit different.
>> > > - Define a single enumeration named READING_MODULE_COMPRESSED.
>> > >
>> > > - In module/main.c add a new security_kernel_post_read_file() call immediately
>> > > after decompressing the kernel module. Like a previous version of this patch,
>> > > call kernel_read_file() with either READING_MODULE or READING_MODULE_COMPRESSED
>> > > based on MODULE_INIT_COMPRESSED_FILE.
>> > >
>> > > - In ima_post_read_file() defer verifying the signature when the enumeration is
>> > > READING_MODULE_COMPRESSED. (No need for a new function ima_read_kernel_module.)
>> >
>> > Hi Mimi,
>> >
>> > Thanks for summarizing your conversation with Paul! I can confirm Paul's
>> > approach works
>> > https://github.com/coiby/linux/tree/in_kernel_decompression_ima_no_lsm_hook_paul
>> >
>> > While testing the patch today, I realized there is another
>> > issue/challenge introduced by in-kernel module decompression. IMA
>> > appraisal is to verify the digest of compressed kernel module but
>> > currently the passed buffer is uncompressed module. When IMA uses
>> > uncompressed module data to calculate the digest, xattr signature
>> > verification will fail. If we always make IMA read the original kernel
>> > module data again to calculate the digest, does it look like a
>> > quick-and-dirty fix? If we can assume people won't load kernel module so
>> > often, the performance impact is negligible. Otherwise we may have to
>> > introduce a new LSM hook so IMA can access uncompressed and original
>> > module data one time.
>>
>> ima_collect_measurement() stores the file hash info in the iint and uses that
>> information to verify the signature as stored in the security xattr.
>> Decompressing the kernel module shouldn't affect the xattr signature
>> verification.
>
>In the case when the compressed kernel module hasn't previously been measured or
>appraised before loading the kernel module, we need to "collect" the file data
>hash on READING_MODULE_COMPRESSED, but defer appraising/measuring it.
>
>An alternative to your suggestion of re-reading the original kernel module data
>to calculate the digest or defining a new hook, would be to define "collect" as
>a new "action" and pass the kernel_read_file_id enumeration to
>process_measurement(). IMA_COLLECTED already exists. Only IMA_COLLECT would
>need to be defined. The new collect "action" should be limited to
>func=MODULE_CHECK.
>
>The downside of this alternative is that it requires a new collect rule:
>collect func=MODULE_CHECK mask=MAY_READ uid=0
>appraise func=MODULE_CHECK appraise_type=imasig|modsig
Thank for suggesting an alternative! I've implemented the idea in
https://github.com/coiby/linux/tree/in_kernel_decompression_ima_collect
Note besides a new collect rule, another change is needed. Currently,
process_measurement only accepts enum ima_hooks thus it can't tell if
it's READING_MODULE_COMPRESSED so to only do collect action. So I
create a fake MODULE_COMPRESSED_CHECK func.
And for the idea of re-reading the original kernel module data, it has
been implemented in
https://github.com/coiby/linux/tree/in_kernel_decompression_ima_no_lsm_hook_paul
Both branches have applied your requested three changes including
respecting the 80 char line limit. Additionally, I made a change to the
IPE LSM because of the new READING_MODULE_COMPRESSED kernel_read_file_id
enumerate.
After comparing the two implementations, personally I prefer re-reading
the original kernel module data because the change is smaller and it's
more user-friendly. But if there are other reasons I don't know, I'll
post the patches of the new collect action approach to the mailing list.
--
Best regards,
Coiby
^ permalink raw reply
* Re: [PATCH v2 5/7] kallsyms/bpf: Rename __bpf_address_lookup() to bpf_address_lookup()
From: Alexei Starovoitov @ 2025-11-13 2:50 UTC (permalink / raw)
To: Petr Mladek
Cc: Petr Pavlu, Steven Rostedt, Alexei Starovoitov, Andrew Morton,
Kees Cook, Aaron Tomlin, Daniel Borkmann, John Fastabend,
Masami Hiramatsu, Mark Rutland, Luis Chamberlain, Daniel Gomez,
Sami Tolvanen, LKML, bpf, linux-modules, linux-trace-kernel
In-Reply-To: <20251112142003.182062-6-pmladek@suse.com>
On Wed, Nov 12, 2025 at 6:21 AM Petr Mladek <pmladek@suse.com> wrote:
>
> bpf_address_lookup() has been used only in kallsyms_lookup_buildid().
> It was supposed to set @modname and @modbuildid when the symbol was
> in a module.
>
> But it always just cleared @modname because BPF symbols were never in
> a module. And it did not clear @modbuildid because the pointer was
> not passed.
>
> The wrapper is not longer needed. Both @modname and @modbuildid
is no longer
> are newly always initialized to NULL in kallsyms_lookup_buildid().
are now?
> Remove the wrapper and rename __bpf_address_lookup() to
> bpf_address_lookup() because this variant is used everywhere.
>
> Fixes: 9294523e3768 ("module: add printk formats to add module build ID to stacktraces")
> Signed-off-by: Petr Mladek <pmladek@suse.com>
other than typos in the commit log it lgtm.
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/2] sign-file: Remove support for signing with PKCS#7
From: James Bottomley @ 2025-11-12 15:58 UTC (permalink / raw)
To: David Howells
Cc: Petr Pavlu, David Woodhouse, Luis Chamberlain, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, keyrings, linux-modules,
linux-kernel
In-Reply-To: <1235767.1762962760@warthog.procyon.org.uk>
On Wed, 2025-11-12 at 15:52 +0000, David Howells wrote:
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>
> > > We're looking at moving to ML-DSA, and the CMS support there is
> > > slightly dodgy at the moment, so we need to hold off a bit on
> > > this change.
> >
> > How will removing PKCS7_sign, which can only do sha1 signatures
> > affect that? Is the dodginess that the PKCS7_... API is better than
> > CMS_... for PQS at the moment? In which case we could pretty much
> > do a rip and replace of the CMS_ API if necessary, but that would
> > be a completely separate patch.
>
> OpenSSL-3.5.1's ML-DSA support isn't completely right - in particular
> CMS_NOATTR is not currently supported. I believe there is a fix in
> the works there, but I doubt it has made it to all the distributions
> yet.
I get that PQC in openssl-3.5 is highly experimental, but that merely
means we tell people not to use it for a while. However, what I don't
see is how this impacts PKCS7_sign removal. The CMS API can do a sha1
signature if that's what people want and keeping the PKCS7_sign API
won't prevent anyone with openssl-3.5 installed from trying a PQ
signature.
> I'm only asking that we hold off a cycle; that will probably
> suffice.
Right but why? Is your thought that we'll have to change the CMS_ code
slightly and this might conflict?
Regards,
James
^ permalink raw reply
* Re: [PATCH 2/2] sign-file: Remove support for signing with PKCS#7
From: David Howells @ 2025-11-12 15:52 UTC (permalink / raw)
To: James Bottomley
Cc: dhowells, Petr Pavlu, David Woodhouse, Luis Chamberlain,
Daniel Gomez, Sami Tolvanen, Aaron Tomlin, keyrings,
linux-modules, linux-kernel
In-Reply-To: <0b18e4cd726c6d986e969a78bff0aaaf6affd3a0.camel@HansenPartnership.com>
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> > We're looking at moving to ML-DSA, and the CMS support there is
> > slightly dodgy at the moment, so we need to hold off a bit on this
> > change.
>
> How will removing PKCS7_sign, which can only do sha1 signatures affect
> that? Is the dodginess that the PKCS7_... API is better than CMS_...
> for PQS at the moment? In which case we could pretty much do a rip and
> replace of the CMS_ API if necessary, but that would be a completely
> separate patch.
OpenSSL-3.5.1's ML-DSA support isn't completely right - in particular
CMS_NOATTR is not currently supported. I believe there is a fix in the works
there, but I doubt it has made it to all the distributions yet. I'm only
asking that we hold off a cycle; that will probably suffice.
David
^ permalink raw reply
* Re: [PATCH 2/2] sign-file: Remove support for signing with PKCS#7
From: James Bottomley @ 2025-11-12 15:47 UTC (permalink / raw)
To: David Howells, Petr Pavlu
Cc: David Woodhouse, Luis Chamberlain, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, keyrings, linux-modules, linux-kernel
In-Reply-To: <1234920.1762961817@warthog.procyon.org.uk>
On Wed, 2025-11-12 at 15:36 +0000, David Howells wrote:
> Petr Pavlu <petr.pavlu@suse.com> wrote:
>
> > In practice, since distributions now typically sign modules with
> > SHA-2, for which sign-file already required CMS API support,
> > removing the USE_PKCS7 code shouldn't cause any issues.
>
> We're looking at moving to ML-DSA, and the CMS support there is
> slightly dodgy at the moment, so we need to hold off a bit on this
> change.
How will removing PKCS7_sign, which can only do sha1 signatures affect
that? Is the dodginess that the PKCS7_... API is better than CMS_...
for PQS at the moment? In which case we could pretty much do a rip and
replace of the CMS_ API if necessary, but that would be a completely
separate patch.
Regards,
James
^ permalink raw reply
* Re: [PATCH 2/2] sign-file: Remove support for signing with PKCS#7
From: David Howells @ 2025-11-12 15:36 UTC (permalink / raw)
To: Petr Pavlu
Cc: dhowells, James Bottomley, David Woodhouse, Luis Chamberlain,
Daniel Gomez, Sami Tolvanen, Aaron Tomlin, keyrings,
linux-modules, linux-kernel
In-Reply-To: <e624c242-b297-4bb7-a76a-cbb18b027472@suse.com>
Petr Pavlu <petr.pavlu@suse.com> wrote:
> In practice, since distributions now typically sign modules with SHA-2, for
> which sign-file already required CMS API support, removing the USE_PKCS7
> code shouldn't cause any issues.
We're looking at moving to ML-DSA, and the CMS support there is slightly dodgy
at the moment, so we need to hold off a bit on this change.
Patch 1, removing the option to sign with SHA-1 from the kernel is fine, but
doesn't stop things that are signed with SHA-1 from being verified.
David
^ permalink raw reply
* Re: [PATCH 2/2] sign-file: Remove support for signing with PKCS#7
From: James Bottomley @ 2025-11-12 15:05 UTC (permalink / raw)
To: Petr Pavlu
Cc: David Howells, David Woodhouse, Luis Chamberlain, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, keyrings, linux-modules,
linux-kernel
In-Reply-To: <e624c242-b297-4bb7-a76a-cbb18b027472@suse.com>
On Wed, 2025-11-12 at 14:51 +0100, Petr Pavlu wrote:
> On 11/11/25 5:53 PM, James Bottomley wrote:
> > On Tue, 2025-11-11 at 16:48 +0100, Petr Pavlu wrote:
> > > The PKCS#7 code in sign-file allows for signing only with SHA-1.
> > > Since SHA-1 support for module signing has been removed, drop
> > > PKCS#7 support in favor of using only CMS.
> >
> > The change log is a bit alarmist. CMS really *is* PKCS7 and most
> > literature will refer to CMS as PKCS7. What you're really
> > deprecating is the use of the PKCS7_sign() API which can only
> > produce SHA-1 Signatures ... openssl is fully capable of producing
> > any hash PKCS7 signatures using a different PKCS7_... API set but
> > the CMS_... API is newer.
> >
> > The point being the module signature type is still set to
> > PKEY_ID_PKCS7 so it doesn't square with the commit log saying "drop
> > PKCS#7 support". What you really mean is only use the openssl
> > CMS_... API for producing PKCS7 signatures.
>
> Ok, I plan to update the description to the following in v2:
>
> sign-file: Use only the OpenSSL CMS API for signing
>
> The USE_PKCS7 code in sign-file utilizes PKCS7_sign(), which allows
> signing only with SHA-1. Since SHA-1 support for module signing has
> been removed, drop the use of the OpenSSL PKCS7 API by the tool in
> favor of using only the newer CMS API.
Much better, thanks!
Regards,
James
^ permalink raw reply
* Re: [PATCH v7 2/8] crypto: Add ML-DSA/Dilithium verify support
From: David Howells @ 2025-11-12 14:55 UTC (permalink / raw)
To: Eric Biggers
Cc: dhowells, Herbert Xu, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Jason A . Donenfeld, Ard Biesheuvel,
Stephan Mueller, Lukas Wunner, Ignat Korchagin, linux-crypto,
keyrings, linux-modules, linux-kernel
In-Reply-To: <20251106192016.GA3318@quark>
Eric Biggers <ebiggers@kernel.org> wrote:
> As I mentioned before
> (https://lore.kernel.org/linux-crypto/20250613170456.GA1284@sol/), this
> code should go in lib/crypto/. There seems to be a clean API in
> crypto/ml_dsa/dilithium.h already. Just make that the library API.
It's not that simple, as it turns out. Various of the API structures are
dependent on the strength-specific #include magic stuff.
dilithium_{44,65,87}.h (or parts thereof) are used in the generation of those
structs.
Now, I can move all that stuff into one header file in include/crypto/, but
it's exposing a lot of the internals.
It also requires the caller to do some of the work in expanding the public key
and signature into those API structs, so it's probably better to wrap the
dilithium.h API to a simpler one with just init, update, fini and all-in-one
functions and have the crypto_sig interface call those (the helper functions
are pretty much the wrappers I need anyway).
David
^ permalink raw reply
* [PATCH v2 7/7] kallsyms: Prevent module removal when printing module name and buildid
From: Petr Mladek @ 2025-11-12 14:20 UTC (permalink / raw)
To: Petr Pavlu, Steven Rostedt, Alexei Starovoitov, Andrew Morton,
Kees Cook
Cc: Aaron Tomlin, Daniel Borkmann, John Fastabend, Masami Hiramatsu,
Mark Rutland, Luis Chamberlain, Daniel Gomez, Sami Tolvanen,
linux-kernel, bpf, linux-modules, linux-trace-kernel, Petr Mladek
In-Reply-To: <20251112142003.182062-1-pmladek@suse.com>
kallsyms_lookup_buildid() copies the symbol name into the given buffer
so that it can be safely read anytime later. But it just copies pointers
to mod->name and mod->build_id which might get reused after the related
struct module gets removed.
The lifetime of struct module is synchronized using RCU. Take the rcu
read lock for the entire __sprint_symbol().
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
---
kernel/kallsyms.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 5bc1646f8639..202d39f5493a 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -471,6 +471,9 @@ static int __sprint_symbol(char *buffer, unsigned long address,
unsigned long offset, size;
int len;
+ /* Prevent module removal until modname and modbuildid are printed */
+ guard(rcu)();
+
address += symbol_offset;
len = kallsyms_lookup_buildid(address, &size, &offset, &modname, &buildid,
buffer);
--
2.51.1
^ permalink raw reply related
* [PATCH v2 6/7] kallsyms/ftrace: Set module buildid in ftrace_mod_address_lookup()
From: Petr Mladek @ 2025-11-12 14:20 UTC (permalink / raw)
To: Petr Pavlu, Steven Rostedt, Alexei Starovoitov, Andrew Morton,
Kees Cook
Cc: Aaron Tomlin, Daniel Borkmann, John Fastabend, Masami Hiramatsu,
Mark Rutland, Luis Chamberlain, Daniel Gomez, Sami Tolvanen,
linux-kernel, bpf, linux-modules, linux-trace-kernel, Petr Mladek
In-Reply-To: <20251112142003.182062-1-pmladek@suse.com>
__sprint_symbol() might access an invalid pointer when
kallsyms_lookup_buildid() returns a symbol found by
ftrace_mod_address_lookup().
The ftrace lookup function must set both @modname and @modbuildid
the same way as module_address_lookup().
Fixes: 9294523e3768 ("module: add printk formats to add module build ID to stacktraces")
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Petr Mladek <pmladek@suse.com>
---
include/linux/ftrace.h | 6 ++++--
kernel/kallsyms.c | 4 ++--
kernel/trace/ftrace.c | 5 ++++-
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 7ded7df6e9b5..a003cf1b32d0 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -87,11 +87,13 @@ struct ftrace_hash;
defined(CONFIG_DYNAMIC_FTRACE)
int
ftrace_mod_address_lookup(unsigned long addr, unsigned long *size,
- unsigned long *off, char **modname, char *sym);
+ unsigned long *off, char **modname,
+ const unsigned char **modbuildid, char *sym);
#else
static inline int
ftrace_mod_address_lookup(unsigned long addr, unsigned long *size,
- unsigned long *off, char **modname, char *sym)
+ unsigned long *off, char **modname,
+ const unsigned char **modbuildid, char *sym)
{
return 0;
}
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 97b92fc8871d..5bc1646f8639 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -386,8 +386,8 @@ static int kallsyms_lookup_buildid(unsigned long addr,
ret = bpf_address_lookup(addr, symbolsize, offset, namebuf);
if (!ret)
- ret = ftrace_mod_address_lookup(addr, symbolsize,
- offset, modname, namebuf);
+ ret = ftrace_mod_address_lookup(addr, symbolsize, offset,
+ modname, modbuildid, namebuf);
return ret;
}
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 42bd2ba68a82..11f5096fb60c 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -7678,7 +7678,8 @@ ftrace_func_address_lookup(struct ftrace_mod_map *mod_map,
int
ftrace_mod_address_lookup(unsigned long addr, unsigned long *size,
- unsigned long *off, char **modname, char *sym)
+ unsigned long *off, char **modname,
+ const unsigned char **modbuildid, char *sym)
{
struct ftrace_mod_map *mod_map;
int ret = 0;
@@ -7690,6 +7691,8 @@ ftrace_mod_address_lookup(unsigned long addr, unsigned long *size,
if (ret) {
if (modname)
*modname = mod_map->mod->name;
+ if (modbuildid)
+ *modbuildid = module_buildid(mod_map->mod);
break;
}
}
--
2.51.1
^ permalink raw reply related
* [PATCH v2 5/7] kallsyms/bpf: Rename __bpf_address_lookup() to bpf_address_lookup()
From: Petr Mladek @ 2025-11-12 14:20 UTC (permalink / raw)
To: Petr Pavlu, Steven Rostedt, Alexei Starovoitov, Andrew Morton,
Kees Cook
Cc: Aaron Tomlin, Daniel Borkmann, John Fastabend, Masami Hiramatsu,
Mark Rutland, Luis Chamberlain, Daniel Gomez, Sami Tolvanen,
linux-kernel, bpf, linux-modules, linux-trace-kernel, Petr Mladek
In-Reply-To: <20251112142003.182062-1-pmladek@suse.com>
bpf_address_lookup() has been used only in kallsyms_lookup_buildid().
It was supposed to set @modname and @modbuildid when the symbol was
in a module.
But it always just cleared @modname because BPF symbols were never in
a module. And it did not clear @modbuildid because the pointer was
not passed.
The wrapper is not longer needed. Both @modname and @modbuildid
are newly always initialized to NULL in kallsyms_lookup_buildid().
Remove the wrapper and rename __bpf_address_lookup() to
bpf_address_lookup() because this variant is used everywhere.
Fixes: 9294523e3768 ("module: add printk formats to add module build ID to stacktraces")
Signed-off-by: Petr Mladek <pmladek@suse.com>
---
arch/arm64/net/bpf_jit_comp.c | 2 +-
arch/powerpc/net/bpf_jit_comp.c | 2 +-
include/linux/filter.h | 26 ++++----------------------
kernel/bpf/core.c | 4 ++--
kernel/kallsyms.c | 5 ++---
5 files changed, 10 insertions(+), 29 deletions(-)
diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
index 0c9a50a1e73e..17e6a041ea4d 100644
--- a/arch/arm64/net/bpf_jit_comp.c
+++ b/arch/arm64/net/bpf_jit_comp.c
@@ -2939,7 +2939,7 @@ int bpf_arch_text_poke(void *ip, enum bpf_text_poke_type poke_type,
u64 plt_target = 0ULL;
bool poking_bpf_entry;
- if (!__bpf_address_lookup((unsigned long)ip, &size, &offset, namebuf))
+ if (!bpf_address_lookup((unsigned long)ip, &size, &offset, namebuf))
/* Only poking bpf text is supported. Since kernel function
* entry is set up by ftrace, we reply on ftrace to poke kernel
* functions.
diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index 88ad5ba7b87f..21f7f26a5e2f 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -1122,7 +1122,7 @@ int bpf_arch_text_poke(void *ip, enum bpf_text_poke_type poke_type,
branch_flags = poke_type == BPF_MOD_CALL ? BRANCH_SET_LINK : 0;
/* We currently only support poking bpf programs */
- if (!__bpf_address_lookup(bpf_func, &size, &offset, name)) {
+ if (!bpf_address_lookup(bpf_func, &size, &offset, name)) {
pr_err("%s (0x%lx): kernel/modules are not supported\n", __func__, bpf_func);
return -EOPNOTSUPP;
}
diff --git a/include/linux/filter.h b/include/linux/filter.h
index f5c859b8131a..d500338af6e0 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -1353,24 +1353,13 @@ static inline bool bpf_jit_kallsyms_enabled(void)
return false;
}
-int __bpf_address_lookup(unsigned long addr, unsigned long *size,
- unsigned long *off, char *sym);
+int bpf_address_lookup(unsigned long addr, unsigned long *size,
+ unsigned long *off, char *sym);
bool is_bpf_text_address(unsigned long addr);
int bpf_get_kallsym(unsigned int symnum, unsigned long *value, char *type,
char *sym);
struct bpf_prog *bpf_prog_ksym_find(unsigned long addr);
-static inline int
-bpf_address_lookup(unsigned long addr, unsigned long *size,
- unsigned long *off, char **modname, char *sym)
-{
- int ret = __bpf_address_lookup(addr, size, off, sym);
-
- if (ret && modname)
- *modname = NULL;
- return ret;
-}
-
void bpf_prog_kallsyms_add(struct bpf_prog *fp);
void bpf_prog_kallsyms_del(struct bpf_prog *fp);
@@ -1409,8 +1398,8 @@ static inline bool bpf_jit_kallsyms_enabled(void)
}
static inline int
-__bpf_address_lookup(unsigned long addr, unsigned long *size,
- unsigned long *off, char *sym)
+bpf_address_lookup(unsigned long addr, unsigned long *size,
+ unsigned long *off, char *sym)
{
return 0;
}
@@ -1431,13 +1420,6 @@ static inline struct bpf_prog *bpf_prog_ksym_find(unsigned long addr)
return NULL;
}
-static inline int
-bpf_address_lookup(unsigned long addr, unsigned long *size,
- unsigned long *off, char **modname, char *sym)
-{
- return 0;
-}
-
static inline void bpf_prog_kallsyms_add(struct bpf_prog *fp)
{
}
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index d595fe512498..c2278f392e93 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -713,8 +713,8 @@ static struct bpf_ksym *bpf_ksym_find(unsigned long addr)
return n ? container_of(n, struct bpf_ksym, tnode) : NULL;
}
-int __bpf_address_lookup(unsigned long addr, unsigned long *size,
- unsigned long *off, char *sym)
+int bpf_address_lookup(unsigned long addr, unsigned long *size,
+ unsigned long *off, char *sym)
{
struct bpf_ksym *ksym;
int ret = 0;
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index f25b122397ce..97b92fc8871d 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -342,7 +342,7 @@ int kallsyms_lookup_size_offset(unsigned long addr, unsigned long *symbolsize,
return 1;
}
return !!module_address_lookup(addr, symbolsize, offset, NULL, NULL, namebuf) ||
- !!__bpf_address_lookup(addr, symbolsize, offset, namebuf);
+ !!bpf_address_lookup(addr, symbolsize, offset, namebuf);
}
static int kallsyms_lookup_buildid(unsigned long addr,
@@ -383,8 +383,7 @@ static int kallsyms_lookup_buildid(unsigned long addr,
ret = module_address_lookup(addr, symbolsize, offset,
modname, modbuildid, namebuf);
if (!ret)
- ret = bpf_address_lookup(addr, symbolsize,
- offset, modname, namebuf);
+ ret = bpf_address_lookup(addr, symbolsize, offset, namebuf);
if (!ret)
ret = ftrace_mod_address_lookup(addr, symbolsize,
--
2.51.1
^ permalink raw reply related
* [PATCH v2 4/7] kallsyms: Cleanup code for appending the module buildid
From: Petr Mladek @ 2025-11-12 14:20 UTC (permalink / raw)
To: Petr Pavlu, Steven Rostedt, Alexei Starovoitov, Andrew Morton,
Kees Cook
Cc: Aaron Tomlin, Daniel Borkmann, John Fastabend, Masami Hiramatsu,
Mark Rutland, Luis Chamberlain, Daniel Gomez, Sami Tolvanen,
linux-kernel, bpf, linux-modules, linux-trace-kernel, Petr Mladek
In-Reply-To: <20251112142003.182062-1-pmladek@suse.com>
Put the code for appending the optional "buildid" into a helper
function, It makes __sprint_symbol() better readable.
Also print a warning when the "modname" is set and the "buildid" isn't.
It might catch a situation when some lookup function in
kallsyms_lookup_buildid() does not handle the "buildid".
Use pr_*_once() to avoid an infinite recursion when the function
is called from printk(). The recursion is rather theoretical but
better be on the safe side.
Signed-off-by: Petr Mladek <pmladek@suse.com>
---
kernel/kallsyms.c | 42 +++++++++++++++++++++++++++++++++---------
1 file changed, 33 insertions(+), 9 deletions(-)
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index ffb64eaa0505..f25b122397ce 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -432,6 +432,37 @@ int lookup_symbol_name(unsigned long addr, char *symname)
return lookup_module_symbol_name(addr, symname);
}
+#ifdef CONFIG_STACKTRACE_BUILD_ID
+
+static int append_buildid(char *buffer, const char *modname,
+ const unsigned char *buildid)
+{
+ if (!modname)
+ return 0;
+
+ if (!buildid) {
+ pr_warn_once("Undefined buildid for the module %s\n", modname);
+ return 0;
+ }
+
+ /* build ID should match length of sprintf */
+#ifdef CONFIG_MODULES
+ static_assert(sizeof(typeof_member(struct module, build_id)) == 20);
+#endif
+
+ return sprintf(buffer, " %20phN", buildid);
+}
+
+#else /* CONFIG_STACKTRACE_BUILD_ID */
+
+static int append_buildid(char *buffer, const char *modname,
+ const unsigned char *buildid)
+{
+ return 0;
+}
+
+#endif /* CONFIG_STACKTRACE_BUILD_ID */
+
/* Look up a kernel symbol and return it in a text buffer. */
static int __sprint_symbol(char *buffer, unsigned long address,
int symbol_offset, int add_offset, int add_buildid)
@@ -454,15 +485,8 @@ static int __sprint_symbol(char *buffer, unsigned long address,
if (modname) {
len += sprintf(buffer + len, " [%s", modname);
-#if IS_ENABLED(CONFIG_STACKTRACE_BUILD_ID)
- if (add_buildid && buildid) {
- /* build ID should match length of sprintf */
-#if IS_ENABLED(CONFIG_MODULES)
- static_assert(sizeof(typeof_member(struct module, build_id)) == 20);
-#endif
- len += sprintf(buffer + len, " %20phN", buildid);
- }
-#endif
+ if (add_buildid)
+ len += append_buildid(buffer + len, modname, buildid);
len += sprintf(buffer + len, "]");
}
--
2.51.1
^ permalink raw reply related
* [PATCH v2 3/7] module: Add helper function for reading module_buildid()
From: Petr Mladek @ 2025-11-12 14:19 UTC (permalink / raw)
To: Petr Pavlu, Steven Rostedt, Alexei Starovoitov, Andrew Morton,
Kees Cook
Cc: Aaron Tomlin, Daniel Borkmann, John Fastabend, Masami Hiramatsu,
Mark Rutland, Luis Chamberlain, Daniel Gomez, Sami Tolvanen,
linux-kernel, bpf, linux-modules, linux-trace-kernel, Petr Mladek,
Daniel Gomez
In-Reply-To: <20251112142003.182062-1-pmladek@suse.com>
Add a helper function for reading the optional "build_id" member
of struct module. It is going to be used also in
ftrace_mod_address_lookup().
Use "#ifdef" instead of "#if IS_ENABLED()" to match the declaration
of the optional field in struct module.
Reviewed-by: Daniel Gomez <da.gomez@samsung.com>
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
---
include/linux/module.h | 9 +++++++++
kernel/module/kallsyms.c | 9 ++-------
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index e135cc79acee..4decae2b1675 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -747,6 +747,15 @@ static inline void __module_get(struct module *module)
__mod ? __mod->name : "kernel"; \
})
+static inline const unsigned char *module_buildid(struct module *mod)
+{
+#ifdef CONFIG_STACKTRACE_BUILD_ID
+ return mod->build_id;
+#else
+ return NULL;
+#endif
+}
+
/* Dereference module function descriptor */
void *dereference_module_function_descriptor(struct module *mod, void *ptr);
diff --git a/kernel/module/kallsyms.c b/kernel/module/kallsyms.c
index 00a60796327c..0fc11e45df9b 100644
--- a/kernel/module/kallsyms.c
+++ b/kernel/module/kallsyms.c
@@ -334,13 +334,8 @@ int module_address_lookup(unsigned long addr,
if (mod) {
if (modname)
*modname = mod->name;
- if (modbuildid) {
-#if IS_ENABLED(CONFIG_STACKTRACE_BUILD_ID)
- *modbuildid = mod->build_id;
-#else
- *modbuildid = NULL;
-#endif
- }
+ if (modbuildid)
+ *modbuildid = module_buildid(mod);
sym = find_kallsyms_symbol(mod, addr, size, offset);
--
2.51.1
^ permalink raw reply related
* [PATCH v2 2/7] kallsyms: Clean up modname and modbuildid initialization in kallsyms_lookup_buildid()
From: Petr Mladek @ 2025-11-12 14:19 UTC (permalink / raw)
To: Petr Pavlu, Steven Rostedt, Alexei Starovoitov, Andrew Morton,
Kees Cook
Cc: Aaron Tomlin, Daniel Borkmann, John Fastabend, Masami Hiramatsu,
Mark Rutland, Luis Chamberlain, Daniel Gomez, Sami Tolvanen,
linux-kernel, bpf, linux-modules, linux-trace-kernel, Petr Mladek
In-Reply-To: <20251112142003.182062-1-pmladek@suse.com>
The @modname and @modbuildid optional return parameters are set only
when the symbol is in a module.
Always initialize them so that they do not need to be cleared when
the module is not in a module. It simplifies the logic and makes
the code even slightly more safe.
Note that bpf_address_lookup() function will get updated in a separate
patch.
Signed-off-by: Petr Mladek <pmladek@suse.com>
---
kernel/kallsyms.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index e08c1e57fc0d..ffb64eaa0505 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -359,6 +359,14 @@ static int kallsyms_lookup_buildid(unsigned long addr,
* or empty string.
*/
namebuf[0] = 0;
+ /*
+ * Initialize the module-related return values. They are not set
+ * when the symbol is in vmlinux or it is a bpf address.
+ */
+ if (modname)
+ *modname = NULL;
+ if (modbuildid)
+ *modbuildid = NULL;
if (is_ksym_addr(addr)) {
unsigned long pos;
@@ -367,10 +375,6 @@ static int kallsyms_lookup_buildid(unsigned long addr,
/* Grab name */
kallsyms_expand_symbol(get_symbol_offset(pos),
namebuf, KSYM_NAME_LEN);
- if (modname)
- *modname = NULL;
- if (modbuildid)
- *modbuildid = NULL;
return strlen(namebuf);
}
--
2.51.1
^ permalink raw reply related
* [PATCH v2 1/7] kallsyms: Clean up @namebuf initialization in kallsyms_lookup_buildid()
From: Petr Mladek @ 2025-11-12 14:19 UTC (permalink / raw)
To: Petr Pavlu, Steven Rostedt, Alexei Starovoitov, Andrew Morton,
Kees Cook
Cc: Aaron Tomlin, Daniel Borkmann, John Fastabend, Masami Hiramatsu,
Mark Rutland, Luis Chamberlain, Daniel Gomez, Sami Tolvanen,
linux-kernel, bpf, linux-modules, linux-trace-kernel, Petr Mladek
In-Reply-To: <20251112142003.182062-1-pmladek@suse.com>
The function kallsyms_lookup_buildid() initializes the given @namebuf
by clearing the first and the last byte. It is not clear why.
The 1st byte makes sense because some callers ignore the return code
and expect that the buffer contains a valid string, for example:
- function_stat_show()
- kallsyms_lookup()
- kallsyms_lookup_buildid()
The initialization of the last byte does not make much sense because it
can later be overwritten. Fortunately, it seems that all called
functions behave correctly:
- kallsyms_expand_symbol() explicitly adds the trailing '\0'
at the end of the function.
- All *__address_lookup() functions either use the safe strscpy()
or they do not touch the buffer at all.
Document the reason for clearing the first byte. And remove the useless
initialization of the last byte.
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
---
kernel/kallsyms.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 1e7635864124..e08c1e57fc0d 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -352,7 +352,12 @@ static int kallsyms_lookup_buildid(unsigned long addr,
{
int ret;
- namebuf[KSYM_NAME_LEN - 1] = 0;
+ /*
+ * kallsyms_lookus() returns pointer to namebuf on success and
+ * NULL on error. But some callers ignore the return value.
+ * Instead they expect @namebuf filled either with valid
+ * or empty string.
+ */
namebuf[0] = 0;
if (is_ksym_addr(addr)) {
--
2.51.1
^ permalink raw reply related
* [PATCH v2 0/7] kallsyms: Prevent invalid access when showing module buildid
From: Petr Mladek @ 2025-11-12 14:19 UTC (permalink / raw)
To: Petr Pavlu, Steven Rostedt, Alexei Starovoitov, Andrew Morton,
Kees Cook
Cc: Aaron Tomlin, Daniel Borkmann, John Fastabend, Masami Hiramatsu,
Mark Rutland, Luis Chamberlain, Daniel Gomez, Sami Tolvanen,
linux-kernel, bpf, linux-modules, linux-trace-kernel, Petr Mladek
This patchset is cleaning up kallsyms code related to module buildid.
It is fixing an invalid access when printing backtraces, see [v1] for
more details:
+ 1st..4th patches are preparatory.
+ 5th and 6th patches are fixing bpf and ftrace related APIs.
+ 7th patch prevents a potential race.
Changes against [v1]:
+ Added existing Reviewed-by tags.
+ Shuffled patches to update the kallsyms_lookup_buildid() initialization
code 1st.
+ Initialized also *modname and *modbuildid in kallsyms_lookup_buildid().
+ Renamed __bpf_address_lookup() to bpf_address_lookup() and used it
in kallsyms_lookup_buildid(). Did this instead of passing @modbuildid
parameter just to clear it.
[v1] https://lore.kernel.org/r/20251105142319.1139183-1-pmladek@suse.com
Petr Mladek (7):
kallsyms: Clean up @namebuf initialization in
kallsyms_lookup_buildid()
kallsyms: Clean up modname and modbuildid initialization in
kallsyms_lookup_buildid()
module: Add helper function for reading module_buildid()
kallsyms: Cleanup code for appending the module buildid
kallsyms/bpf: Rename __bpf_address_lookup() to bpf_address_lookup()
kallsyms/ftrace: Set module buildid in ftrace_mod_address_lookup()
kallsyms: Prevent module removal when printing module name and buildid
arch/arm64/net/bpf_jit_comp.c | 2 +-
arch/powerpc/net/bpf_jit_comp.c | 2 +-
include/linux/filter.h | 26 ++----------
include/linux/ftrace.h | 6 ++-
include/linux/module.h | 9 ++++
kernel/bpf/core.c | 4 +-
kernel/kallsyms.c | 73 ++++++++++++++++++++++++---------
kernel/module/kallsyms.c | 9 +---
kernel/trace/ftrace.c | 5 ++-
9 files changed, 81 insertions(+), 55 deletions(-)
--
2.51.1
^ permalink raw reply
* Re: [PATCH 2/2] sign-file: Remove support for signing with PKCS#7
From: Petr Pavlu @ 2025-11-12 13:51 UTC (permalink / raw)
To: James Bottomley
Cc: David Howells, David Woodhouse, Luis Chamberlain, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, keyrings, linux-modules,
linux-kernel
In-Reply-To: <922480ff44bda3b6ecfda1ae780c659644560f94.camel@HansenPartnership.com>
On 11/11/25 5:53 PM, James Bottomley wrote:
> On Tue, 2025-11-11 at 16:48 +0100, Petr Pavlu wrote:
>> The PKCS#7 code in sign-file allows for signing only with SHA-1.
>> Since SHA-1 support for module signing has been removed, drop PKCS#7
>> support in favor of using only CMS.
>
> The change log is a bit alarmist. CMS really *is* PKCS7 and most
> literature will refer to CMS as PKCS7. What you're really deprecating
> is the use of the PKCS7_sign() API which can only produce SHA-1
> Signatures ... openssl is fully capable of producing any hash PKCS7
> signatures using a different PKCS7_... API set but the CMS_... API is
> newer.
>
> The point being the module signature type is still set to PKEY_ID_PKCS7
> so it doesn't square with the commit log saying "drop PKCS#7 support".
> What you really mean is only use the openssl CMS_... API for producing
> PKCS7 signatures.
Ok, I plan to update the description to the following in v2:
sign-file: Use only the OpenSSL CMS API for signing
The USE_PKCS7 code in sign-file utilizes PKCS7_sign(), which allows signing
only with SHA-1. Since SHA-1 support for module signing has been removed,
drop the use of the OpenSSL PKCS7 API by the tool in favor of using only
the newer CMS API.
The use of the PKCS7 API is selected by the following:
#if defined(LIBRESSL_VERSION_NUMBER) || \
OPENSSL_VERSION_NUMBER < 0x10000000L || \
defined(OPENSSL_NO_CMS)
#define USE_PKCS7
#endif
Looking at the individual ifdefs:
* LIBRESSL_VERSION_NUMBER: LibreSSL added the CMS API implementation from
OpenSSL in 3.1.0, making the ifdef no longer relevant. This version was
released on April 8, 2020.
* OPENSSL_VERSION_NUMBER < 0x10000000L: OpenSSL 1.0.0 was released on March
29, 2010. Supporting earlier versions should no longer be necessary. The
file Documentation/process/changes.rst already states that at least
version 1.0.0 is required to build the kernel.
* OPENSSL_NO_CMS: OpenSSL can be configured with "no-cms" to disable CMS
support. In this case, sign-file will no longer be usable. The CMS API
support is now required.
In practice, since distributions now typically sign modules with SHA-2, for
which sign-file already required CMS API support, removing the USE_PKCS7
code shouldn't cause any issues.
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH 1/2] module: Remove SHA-1 support for module signing
From: Aaron Tomlin @ 2025-11-11 22:37 UTC (permalink / raw)
To: Petr Pavlu
Cc: David Howells, David Woodhouse, Luis Chamberlain, Daniel Gomez,
Sami Tolvanen, keyrings, linux-modules, linux-kernel
In-Reply-To: <20251111154923.978181-2-petr.pavlu@suse.com>
On Tue, Nov 11, 2025 at 04:48:31PM +0100, Petr Pavlu wrote:
> SHA-1 is considered deprecated and insecure due to vulnerabilities that can
> lead to hash collisions. Most distributions have already been using SHA-2
> for module signing because of this. The default was also changed last year
> from SHA-1 to SHA-512 in commit f3b93547b91a ("module: sign with sha512
> instead of sha1 by default"). This was not reported to cause any issues.
> Therefore, it now seems to be a good time to remove SHA-1 support for
> module signing.
>
> Commit 16ab7cb5825f ("crypto: pkcs7 - remove sha1 support") previously
> removed support for reading PKCS#7/CMS signed with SHA-1, along with the
> ability to use SHA-1 for module signing. This change broke iwd and was
> subsequently completely reverted in commit 203a6763ab69 ("Revert "crypto:
> pkcs7 - remove sha1 support""). However, dropping only the support for
> using SHA-1 for module signing is unrelated and can still be done
> separately.
>
> Note that this change only removes support for new modules to be SHA-1
> signed, but already signed modules can still be loaded.
>
> Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
> ---
> kernel/module/Kconfig | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig
> index 2a1beebf1d37..be74917802ad 100644
> --- a/kernel/module/Kconfig
> +++ b/kernel/module/Kconfig
> @@ -299,10 +299,6 @@ choice
> possible to load a signed module containing the algorithm to check
> the signature on that module.
>
> -config MODULE_SIG_SHA1
> - bool "SHA-1"
> - select CRYPTO_SHA1
> -
> config MODULE_SIG_SHA256
> bool "SHA-256"
> select CRYPTO_SHA256
> @@ -332,7 +328,6 @@ endchoice
> config MODULE_SIG_HASH
> string
> depends on MODULE_SIG || IMA_APPRAISE_MODSIG
> - default "sha1" if MODULE_SIG_SHA1
> default "sha256" if MODULE_SIG_SHA256
> default "sha384" if MODULE_SIG_SHA384
> default "sha512" if MODULE_SIG_SHA512
> --
> 2.51.1
>
Agreed.
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
--
Aaron Tomlin
^ permalink raw reply
* Re: Only rust/bindings.o build fail on rust-1.91.0
From: Sami Tolvanen @ 2025-11-11 21:52 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Haiyue Wang, rust-for-linux, Miguel Ojeda, linux-modules,
Linux Kbuild mailing list
In-Reply-To: <CANiq72n09yx9ZjOtOb3-3rPfpPLKaJZ2fs_Bmpbz28Y8U05snA@mail.gmail.com>
Hi Miguel,
On Tue, Nov 11, 2025 at 1:41 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Sat, Nov 8, 2025 at 6:08 AM Miguel Ojeda
> <miguel.ojeda.sandonis@gmail.com> wrote:
> >
> > Exactly, that is what I was suggesting in the other thread about
> > editing the `cmd` command or directly teaching `genkallksyms` to
> > auto-skip, but I didn't know if there was a reason you didn't do that
> > originally instead of having (some of) the `skip_*` lines in the
> > `Makefile`.
> >
> > If not, then I assume we could already remove some of those lines,
> > e.g. the one for `ffi.o` (no need to do it on the fix, of course,
> > better to keep it minimal, but just to confirm there is no hidden
> > reason there).
>
> For (cross-)reference: I sent "v2" of the fix, essentially taking your
> patch and my commit log and putting them together -- please let me
> know if this is with you!
>
> https://lore.kernel.org/rust-for-linux/20251110131913.1789896-1-ojeda@kernel.org/
Yes, that looks good to me. Thanks for picking this up!
Sami
^ permalink raw reply
* Re: Only rust/bindings.o build fail on rust-1.91.0
From: Miguel Ojeda @ 2025-11-11 21:41 UTC (permalink / raw)
To: Sami Tolvanen
Cc: Haiyue Wang, rust-for-linux, Miguel Ojeda, linux-modules,
Linux Kbuild mailing list
In-Reply-To: <CANiq72mLbEVqX-uBtqy+_wru9CRRb3PL3qFqYEcjpZdNyZGd2w@mail.gmail.com>
On Sat, Nov 8, 2025 at 6:08 AM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> Exactly, that is what I was suggesting in the other thread about
> editing the `cmd` command or directly teaching `genkallksyms` to
> auto-skip, but I didn't know if there was a reason you didn't do that
> originally instead of having (some of) the `skip_*` lines in the
> `Makefile`.
>
> If not, then I assume we could already remove some of those lines,
> e.g. the one for `ffi.o` (no need to do it on the fix, of course,
> better to keep it minimal, but just to confirm there is no hidden
> reason there).
For (cross-)reference: I sent "v2" of the fix, essentially taking your
patch and my commit log and putting them together -- please let me
know if this is with you!
https://lore.kernel.org/rust-for-linux/20251110131913.1789896-1-ojeda@kernel.org/
Thanks!
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v2] gendwarfksyms: Skip files with no exports
From: Miguel Ojeda @ 2025-11-11 19:45 UTC (permalink / raw)
To: sedat.dilek
Cc: Miguel Ojeda, Sami Tolvanen, Alex Gaynor, linux-modules,
linux-kbuild, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, rust-for-linux, linux-kernel, patches, stable,
Haiyue Wang
In-Reply-To: <CA+icZUVcHfLru9SRfhNGToiRmyOY+fLw-ASEvQakZYfU1Kxq4g@mail.gmail.com>
On Tue, Nov 11, 2025 at 4:25 PM Sedat Dilek <sedat.dilek@gmail.com> wrote:
>
> I switched over to gendwarfksyms in the very early testing days.
> Faster builds. DWARFv5 fan.
>
> And was using v5 of Sami's patchset against Linux v6.12 as it cleanly applied.
>
> Last week, I jumped over to Linux v6.17.6 and the next testing will be
> Linux v6.18-rc5+ (upcoming next LTS kernel-version).
>
> I will try this patch - might be you will get a Tested-by.
Sound good -- I have applied it to start getting testing, but if you
have a tag in the next day or so, I can add it.
Thanks!
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v2] gendwarfksyms: Skip files with no exports
From: Miguel Ojeda @ 2025-11-11 19:44 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Sami Tolvanen, Alex Gaynor, linux-modules, linux-kbuild,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich,
rust-for-linux, linux-kernel, patches, stable, Haiyue Wang
In-Reply-To: <20251110131913.1789896-1-ojeda@kernel.org>
On Mon, Nov 10, 2025 at 2:19 PM Miguel Ojeda <ojeda@kernel.org> wrote:
>
> From: Sami Tolvanen <samitolvanen@google.com>
>
> Starting with Rust 1.91.0 (released 2025-10-30), in upstream commit
> ab91a63d403b ("Ignore intrinsic calls in cross-crate-inlining cost model")
> [1][2], `bindings.o` stops containing DWARF debug information because the
> `Default` implementations contained `write_bytes()` calls which are now
> ignored in that cost model (note that `CLIPPY=1` does not reproduce it).
>
> This means `gendwarfksyms` complains:
>
> RUSTC L rust/bindings.o
> error: gendwarfksyms: process_module: dwarf_get_units failed: no debugging information?
>
> There are several alternatives that would work here: conditionally
> skipping in the cases needed (but that is subtle and brittle), forcing
> DWARF generation with e.g. a dummy `static` (ugly and we may need to
> do it in several crates), skipping the call to the tool in the Kbuild
> command when there are no exports (fine) or teaching the tool to do so
> itself (simple and clean).
>
> Thus do the last one: don't attempt to process files if we have no symbol
> versions to calculate.
>
> [ I used the commit log of my patch linked below since it explained the
> root issue and expanded it a bit more to summarize the alternatives.
>
> - Miguel ]
>
> Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
> Reported-by: Haiyue Wang <haiyuewa@163.com>
> Closes: https://lore.kernel.org/rust-for-linux/b8c1c73d-bf8b-4bf2-beb1-84ffdcd60547@163.com/
> Suggested-by: Miguel Ojeda <ojeda@kernel.org>
> Link: https://lore.kernel.org/rust-for-linux/CANiq72nKC5r24VHAp9oUPR1HVPqT+=0ab9N0w6GqTF-kJOeiSw@mail.gmail.com/
> Link: https://github.com/rust-lang/rust/commit/ab91a63d403b0105cacd72809cd292a72984ed99 [1]
> Link: https://github.com/rust-lang/rust/pull/145910 [2]
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Applied to `rust-fixes` to start getting some testing.
If someone doesn't want it, then please let me know.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v2 0/3] module: Add compile-time check for embedded NUL characters
From: Uwe Kleine-König @ 2025-11-11 17:52 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Daniel Gomez, Kees Cook, Luis Chamberlain, Hans Verkuil,
Malcolm Priestley, Mauro Carvalho Chehab, Hans Verkuil,
Rusty Russell, Petr Pavlu, Sami Tolvanen, linux-kernel,
linux-media, linux-modules, linux-hardening
In-Reply-To: <aRMhLEs9NpGexL7B@black.igk.intel.com>
[-- Attachment #1: Type: text/plain, Size: 732 bytes --]
Helo Andy,
On Tue, Nov 11, 2025 at 12:42:36PM +0100, Andy Shevchenko wrote:
> Folks, are you aware that this change blown up the sparse?
> Now there is a "bad constant expression" to each MODULE_*() macro line.
>
> Nice that Uwe is in the Cc list, so IIRC he is Debian maintainer for sparse
> and perhaps has an influence to it to some extent.
To be honest, in the nearer past I'm very passive on the sparse
maintainer side and even stopped using it as it fails on guard locking.
My impression is also that upstream isn't very active any more, but that
might have been temporal and wrong as I stopped looking.
If there is an outcome and a patch to cherry-pick into the Debian
packaging, give me a ping.
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] sign-file: Remove support for signing with PKCS#7
From: James Bottomley @ 2025-11-11 16:53 UTC (permalink / raw)
To: Petr Pavlu, David Howells, David Woodhouse, Luis Chamberlain,
Daniel Gomez, Sami Tolvanen, Aaron Tomlin
Cc: keyrings, linux-modules, linux-kernel
In-Reply-To: <20251111154923.978181-3-petr.pavlu@suse.com>
On Tue, 2025-11-11 at 16:48 +0100, Petr Pavlu wrote:
> The PKCS#7 code in sign-file allows for signing only with SHA-1.
> Since SHA-1 support for module signing has been removed, drop PKCS#7
> support in favor of using only CMS.
The change log is a bit alarmist. CMS really *is* PKCS7 and most
literature will refer to CMS as PKCS7. What you're really deprecating
is the use of the PKCS7_sign() API which can only produce SHA-1
Signatures ... openssl is fully capable of producing any hash PKCS7
signatures using a different PKCS7_... API set but the CMS_... API is
newer.
The point being the module signature type is still set to PKEY_ID_PKCS7
so it doesn't square with the commit log saying "drop PKCS#7 support".
What you really mean is only use the openssl CMS_... API for producing
PKCS7 signatures.
Regards,
James
^ permalink raw reply
* Re: [PATCH 0/2] module: Remove SHA-1 support for module signing
From: Sami Tolvanen @ 2025-11-11 16:22 UTC (permalink / raw)
To: Petr Pavlu
Cc: David Howells, David Woodhouse, Luis Chamberlain, Daniel Gomez,
Aaron Tomlin, keyrings, linux-modules, linux-kernel
In-Reply-To: <20251111154923.978181-1-petr.pavlu@suse.com>
Hi Petr,
On Tue, Nov 11, 2025 at 7:49 AM Petr Pavlu <petr.pavlu@suse.com> wrote:
>
> SHA-1 is considered deprecated and insecure due to vulnerabilities that can
> lead to hash collisions. Most distributions have already been using SHA-2
> for module signing because of this. The default was also changed last year
> from SHA-1 to SHA-512 in f3b93547b91a ("module: sign with sha512 instead of
> sha1 by default"). This was not reported to cause any issues. Therefore, it
> now seems to be a good time to remove SHA-1 support for module signing.
>
> Looking at the configs of several distributions [1], it seems only Android
> still uses SHA-1 for module signing.
>
> @Sami, it this correct and is there a specific reason for using SHA-1?
It looks like GKI just uses the defaults here. Overall, Android
doesn't rely on module signing for security, it's only used to
differentiate between module types. Dropping SHA-1 support sounds like
a good idea to me.
> Note: The second patch has a minor conflict with the sign-file update in the
> series "lib/crypto: Add ML-DSA signing" [2].
>
> [1] https://oracle.github.io/kconfigs/?config=UTS_RELEASE&config=MODULE_SIG_SHA1&version=be8f5f6abf0b0979be20ee8d9afa2a49a13500b8
> [2] https://lore.kernel.org/linux-crypto/61637.1762509938@warthog.procyon.org.uk/
>
> Petr Pavlu (2):
> module: Remove SHA-1 support for module signing
> sign-file: Remove support for signing with PKCS#7
>
> kernel/module/Kconfig | 5 ----
> scripts/sign-file.c | 66 ++-----------------------------------------
> 2 files changed, 3 insertions(+), 68 deletions(-)
For the series:
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Sami
^ 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