* Re: Only rust/bindings.o build fail on rust-1.91.0
From: Miguel Ojeda @ 2025-11-06 17:54 UTC (permalink / raw)
To: Sami Tolvanen
Cc: Haiyue Wang, rust-for-linux, Miguel Ojeda, linux-modules,
Linux Kbuild mailing list
In-Reply-To: <CABCJKud0G+Xh+Wbtg4SDGvk4Yh5nmt5YgHEPj-H0y8GO5R3Amw@mail.gmail.com>
On Thu, Nov 6, 2025 at 5:07 PM Sami Tolvanen <samitolvanen@google.com> wrote:
>
> I can reproduce the issue. With rustc 1.90, rust/bindings.o has
> debugging information, but with 1.91, it no longer does:
>
> $ dwarfdump rust/bindings.o
> No DWARF information present in rust/bindings.o
Same, reproduced as well.
Bisecting nightlies, it seemed to happen between:
rustc 1.91.0-nightly (12eb345e5 2025-09-07)
rustc 1.91.0-nightly (9c27f27ea 2025-09-08)
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v7 2/8] crypto: Add ML-DSA/Dilithium verify support
From: Eric Biggers @ 2025-11-06 19:20 UTC (permalink / raw)
To: David Howells
Cc: 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: <20251106174456.31818-3-dhowells@redhat.com>
On Thu, Nov 06, 2025 at 05:44:46PM +0000, David Howells wrote:
> The interface to this code is through the crypto_sig API as the PKCS#7 code
> wants to use that rather than calling it directly. As such, I've placed it
> in crypto/ rather than lib/crypto/. Only the verification hooks are
> implemented; the signing hooks return an error.
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.
If "crypto_sig" support is really needed too, then put that in
crypto/ml-dsa.c, built on top of the library API. It's not clear the
crypto_sig support is very useful, though. For one, you had to add
ML-DSA specific logic to the calling code anyway (see "pkcs7: Allow the
signing algo to calculate the digest itself").
- Eric
^ permalink raw reply
* Re: [PATCH v2] lsm,ima: new LSM hook security_kernel_module_read_file to access decompressed kernel module
From: Mimi Zohar @ 2025-11-06 22:15 UTC (permalink / raw)
To: Coiby Xu
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: <d24wnmefebnheerigmh6ts5yskkutz726l6a2f6g5s3s5fhhrv@osaactobwb5g>
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.
The patch with a few minor changes looks good:
- READDING_MODULE_CHECK -> READING_MODULE_CHECK
- Fix the enumeration name in ima_main.c
- scripts/checkpatch.pl code/comment line length has been relaxed to 100 chars,
but the section "Breaking long lines and strings" in
Documentation/process/coding-style.rst still recommends 80 characters.
There are cases where it is necessary to go over the 80 char line limit for
readability, but in general both Roberto and I prefer, as much as possible, to
limit the line length to 80 char. To detect where/when the line limit is
greater than 80 chars, use the scripts/checkpatch.pl "--max-line-length=80"
option.
After fixing the patch, please post it to linux-integrity mailing list.
--
thanks,
Mimi
^ permalink raw reply
* [PATCH v7 8/8] modsign: Enable ML-DSA module signing
From: David Howells @ 2025-11-07 10:05 UTC (permalink / raw)
Cc: dhowells, Herbert Xu, Eric Biggers, 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: <20251106174456.31818-1-dhowells@redhat.com>
Allow ML-DSA module signing to be enabled.
Note that openssl's CMS_*() function suite does not, as of openssl-3.5.1,
support the use of CMS_NOATTR with ML-DSA, so the prohibition against using
authenticatedAttributes with module signing has to be removed. The selected
digest then applies only to the algorithm used to calculate the digest
stored in the messageDigest attribute.
The ML-DSA algorithm uses its own internal choice of digest (SHAKE256)
without regard to what's specified in the CMS message. This is, in theory,
configurable, but there's currently no hook in the crypto_sig API to do
that, though possibly it could be done by parameterising the name of the
algorithm, e.g. ("ml-dsa87(sha512)").
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Lukas Wunner <lukas@wunner.de>
cc: Ignat Korchagin <ignat@cloudflare.com>
cc: Stephan Mueller <smueller@chronox.de>
cc: Eric Biggers <ebiggers@kernel.org>
cc: Herbert Xu <herbert@gondor.apana.org.au>
cc: keyrings@vger.kernel.org
cc: linux-crypto@vger.kernel.org
---
Documentation/admin-guide/module-signing.rst | 15 ++++++++-------
certs/Kconfig | 24 ++++++++++++++++++++++++
certs/Makefile | 3 +++
crypto/asymmetric_keys/pkcs7_verify.c | 4 ----
kernel/module/Kconfig | 5 +++++
scripts/sign-file.c | 26 ++++++++++++++++++--------
6 files changed, 58 insertions(+), 19 deletions(-)
diff --git a/Documentation/admin-guide/module-signing.rst b/Documentation/admin-guide/module-signing.rst
index a8667a777490..6daff80c277b 100644
--- a/Documentation/admin-guide/module-signing.rst
+++ b/Documentation/admin-guide/module-signing.rst
@@ -28,10 +28,11 @@ trusted userspace bits.
This facility uses X.509 ITU-T standard certificates to encode the public keys
involved. The signatures are not themselves encoded in any industrial standard
-type. The built-in facility currently only supports the RSA & NIST P-384 ECDSA
-public key signing standard (though it is pluggable and permits others to be
-used). The possible hash algorithms that can be used are SHA-2 and SHA-3 of
-sizes 256, 384, and 512 (the algorithm is selected by data in the signature).
+type. The built-in facility currently only supports the RSA, NIST P-384 ECDSA
+and NIST FIPS-204 ML-DSA (Dilithium) public key signing standards (though it is
+pluggable and permits others to be used). For RSA and ECDSA, the possible hash
+algorithms that can be used are SHA-2 and SHA-3 of sizes 256, 384, and 512 (the
+algorithm is selected by data in the signature); ML-DSA uses SHAKE256.
==========================
@@ -146,9 +147,9 @@ into vmlinux) using parameters in the::
file (which is also generated if it does not already exist).
-One can select between RSA (``MODULE_SIG_KEY_TYPE_RSA``) and ECDSA
-(``MODULE_SIG_KEY_TYPE_ECDSA``) to generate either RSA 4k or NIST
-P-384 keypair.
+One can select between RSA (``MODULE_SIG_KEY_TYPE_RSA``), ECDSA
+(``MODULE_SIG_KEY_TYPE_ECDSA``) and ML-DSA (``MODULE_SIG_KEY_TYPE_ML_DSA``) to
+generate an RSA 4k, a NIST P-384 keypair or an ML-DSA keypair.
It is strongly recommended that you provide your own x509.genkey file.
diff --git a/certs/Kconfig b/certs/Kconfig
index 78307dc25559..f647b944f5da 100644
--- a/certs/Kconfig
+++ b/certs/Kconfig
@@ -39,6 +39,30 @@ config MODULE_SIG_KEY_TYPE_ECDSA
Note: Remove all ECDSA signing keys, e.g. certs/signing_key.pem,
when falling back to building Linux 5.14 and older kernels.
+config MODULE_SIG_KEY_TYPE_ML_DSA_44
+ bool "ML-DSA (Dilithium) 44"
+ select CRYPTO_ML_DSA
+ select LIB_SHA3
+ help
+ Use an ML-DSA (Dilithium) 44 key (NIST FIPS 204) for module signing
+ with a SHAKE256 'hash' of the message.
+
+config MODULE_SIG_KEY_TYPE_ML_DSA_65
+ bool "ML-DSA (Dilithium) 65"
+ select CRYPTO_ML_DSA
+ select LIB_SHA3
+ help
+ Use an ML-DSA (Dilithium) 65 key (NIST FIPS 204) for module signing
+ with a SHAKE256 'hash' of the message.
+
+config MODULE_SIG_KEY_TYPE_ML_DSA_87
+ bool "ML-DSA (Dilithium) 87"
+ select CRYPTO_ML_DSA
+ select LIB_SHA3
+ help
+ Use an ML-DSA (Dilithium) 87 key (NIST FIPS 204) for module signing
+ with a SHAKE256 'hash' of the message.
+
endchoice
config SYSTEM_TRUSTED_KEYRING
diff --git a/certs/Makefile b/certs/Makefile
index f6fa4d8d75e0..231379c91b86 100644
--- a/certs/Makefile
+++ b/certs/Makefile
@@ -43,6 +43,9 @@ targets += x509_certificate_list
ifeq ($(CONFIG_MODULE_SIG_KEY),certs/signing_key.pem)
keytype-$(CONFIG_MODULE_SIG_KEY_TYPE_ECDSA) := -newkey ec -pkeyopt ec_paramgen_curve:secp384r1
+keytype-$(CONFIG_MODULE_SIG_KEY_TYPE_ML_DSA_44) := -newkey ml-dsa-44
+keytype-$(CONFIG_MODULE_SIG_KEY_TYPE_ML_DSA_65) := -newkey ml-dsa-65
+keytype-$(CONFIG_MODULE_SIG_KEY_TYPE_ML_DSA_87) := -newkey ml-dsa-87
quiet_cmd_gen_key = GENKEY $@
cmd_gen_key = openssl req -new -nodes -utf8 -$(CONFIG_MODULE_SIG_HASH) -days 36500 \
diff --git a/crypto/asymmetric_keys/pkcs7_verify.c b/crypto/asymmetric_keys/pkcs7_verify.c
index 0f9f515b784d..f7ea1d41771d 100644
--- a/crypto/asymmetric_keys/pkcs7_verify.c
+++ b/crypto/asymmetric_keys/pkcs7_verify.c
@@ -424,10 +424,6 @@ int pkcs7_verify(struct pkcs7_message *pkcs7,
pr_warn("Invalid module sig (not pkcs7-data)\n");
return -EKEYREJECTED;
}
- if (pkcs7->have_authattrs) {
- pr_warn("Invalid module sig (has authattrs)\n");
- return -EKEYREJECTED;
- }
break;
case VERIFYING_FIRMWARE_SIGNATURE:
if (pkcs7->data_type != OID_data) {
diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig
index 2a1beebf1d37..4b5d1601d537 100644
--- a/kernel/module/Kconfig
+++ b/kernel/module/Kconfig
@@ -327,6 +327,10 @@ config MODULE_SIG_SHA3_512
bool "SHA3-512"
select CRYPTO_SHA3
+config MODULE_SIG_SHAKE256
+ bool "SHAKE256"
+ select CRYPTO_SHA3
+
endchoice
config MODULE_SIG_HASH
@@ -339,6 +343,7 @@ config MODULE_SIG_HASH
default "sha3-256" if MODULE_SIG_SHA3_256
default "sha3-384" if MODULE_SIG_SHA3_384
default "sha3-512" if MODULE_SIG_SHA3_512
+ default "shake256" if MODULE_SIG_SHAKE256
config MODULE_COMPRESS
bool "Module compression"
diff --git a/scripts/sign-file.c b/scripts/sign-file.c
index 7070245edfc1..b726581075f9 100644
--- a/scripts/sign-file.c
+++ b/scripts/sign-file.c
@@ -315,18 +315,28 @@ int main(int argc, char **argv)
ERR(!digest_algo, "EVP_get_digestbyname");
#ifndef USE_PKCS7
+
+ unsigned int flags =
+ CMS_NOCERTS |
+ CMS_PARTIAL |
+ CMS_BINARY |
+ CMS_DETACHED |
+ CMS_STREAM |
+ CMS_NOSMIMECAP |
+ CMS_NO_SIGNING_TIME |
+ use_keyid;
+ if (!EVP_PKEY_is_a(private_key, "ML-DSA-44") &&
+ !EVP_PKEY_is_a(private_key, "ML-DSA-65") &&
+ !EVP_PKEY_is_a(private_key, "ML-DSA-87"))
+ flags |= use_signed_attrs;
+
/* Load the signature message from the digest buffer. */
- cms = CMS_sign(NULL, NULL, NULL, NULL,
- CMS_NOCERTS | CMS_PARTIAL | CMS_BINARY |
- CMS_DETACHED | CMS_STREAM);
+ cms = CMS_sign(NULL, NULL, NULL, NULL, flags);
ERR(!cms, "CMS_sign");
- ERR(!CMS_add1_signer(cms, x509, private_key, digest_algo,
- CMS_NOCERTS | CMS_BINARY |
- CMS_NOSMIMECAP | use_keyid |
- use_signed_attrs),
+ ERR(!CMS_add1_signer(cms, x509, private_key, digest_algo, flags),
"CMS_add1_signer");
- ERR(CMS_final(cms, bm, NULL, CMS_NOCERTS | CMS_BINARY) != 1,
+ ERR(CMS_final(cms, bm, NULL, flags) != 1,
"CMS_final");
#else
^ permalink raw reply related
* Re: [PATCH v7 2/8] crypto: Add ML-DSA/Dilithium verify support
From: David Howells @ 2025-11-07 10:34 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:
> On Thu, Nov 06, 2025 at 05:44:46PM +0000, David Howells wrote:
> > The interface to this code is through the crypto_sig API as the PKCS#7 code
> > wants to use that rather than calling it directly. As such, I've placed it
> > in crypto/ rather than lib/crypto/. Only the verification hooks are
> > implemented; the signing hooks return an error.
>
> 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.
Fine. Is it ever likely to be used directly, I wonder?
There is a downside of moving stuff to lib/crypto/: dynamically loadable
algorithms now need two modules instead of one. For initial module signing,
granted, the algorithms for that must be built in.
> If "crypto_sig" support is really needed too, then put that in
> crypto/ml-dsa.c, built on top of the library API. It's not clear the
> crypto_sig support is very useful, though. For one, you had to add
> ML-DSA specific logic to the calling code anyway (see "pkcs7: Allow the
> signing algo to calculate the digest itself").
The actual signature check still goes through the same code path as everything
else, so crypto_sig will remain the API. Otherwise I have to basically
reimplement crypto_sig inside crypto/asymmetric_keys/, including the on-demand
algorithm loading.
David
^ permalink raw reply
* Re: [PATCH 3/6] kallsyms/bpf: Set module buildid in bpf_address_lookup()
From: Petr Mladek @ 2025-11-07 13:08 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Petr Pavlu, Steven Rostedt, Alexei Starovoitov, Andrew Morton,
Kees Cook, Daniel Borkmann, John Fastabend, Masami Hiramatsu,
Mark Rutland, Luis Chamberlain, Daniel Gomez, Sami Tolvanen, LKML,
bpf, linux-modules, linux-trace-kernel
In-Reply-To: <CAADnVQ+kbQ4uwtKjD1DRCf702v0rEthy6hU4COAU9CyU53wTHg@mail.gmail.com>
On Wed 2025-11-05 18:53:23, Alexei Starovoitov wrote:
> On Wed, Nov 5, 2025 at 6:24 AM Petr Mladek <pmladek@suse.com> wrote:
> >
> > Make bpf_address_lookup() compatible with module_address_lookup()
> > and clear the pointer to @modbuildid together with @modname.
> >
> > It is not strictly needed because __sprint_symbol() reads @modbuildid
> > only when @modname is set. But better be on the safe side and make
> > the API more safe.
> >
> > Fixes: 9294523e3768 ("module: add printk formats to add module build ID to stacktraces")
> > Signed-off-by: Petr Mladek <pmladek@suse.com>
> > ---
> > include/linux/filter.h | 15 +++++++++++----
> > kernel/kallsyms.c | 4 ++--
> > 2 files changed, 13 insertions(+), 6 deletions(-)
> >
> > diff --git a/include/linux/filter.h b/include/linux/filter.h
> > index f5c859b8131a..b7b95840250a 100644
> > --- a/include/linux/filter.h
> > +++ b/include/linux/filter.h
> > @@ -1362,12 +1362,18 @@ 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)
> > + unsigned long *off, char **modname,
> > + const unsigned char **modbuildid, char *sym)
> > {
> > int ret = __bpf_address_lookup(addr, size, off, sym);
> >
> > - if (ret && modname)
> > - *modname = NULL;
> > + if (ret) {
> > + if (modname)
> > + *modname = NULL;
> > + if (modbuildid)
> > + *modbuildid = NULL;
> > + }
> > +
> > return ret;
> > }
> >
> > @@ -1433,7 +1439,8 @@ static inline 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)
> > + unsigned long *off, char **modname,
> > + const unsigned char **modbuildid, char *sym)
> > {
> > return 0;
> > }
> > diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
> > index 9455e3bb07fc..efb12b077220 100644
> > --- a/kernel/kallsyms.c
> > +++ b/kernel/kallsyms.c
> > @@ -374,8 +374,8 @@ 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,
> > + modname, modbuildid, namebuf);
>
> The initial bpf_address_lookup() 8 years ago was trying
> to copy paste args and style of kallsyms_lookup().
> It was odd back then. This change is doubling down on the wrong thing.
> It's really odd to pass a pointer into bpf_address_lookup()
> so it zero initializes it.
> bpf ksyms are in the core kernel. They're never in modules.
> Just call __bpf_address_lookup() here and remove the wrapper.
I agree that it is ugly. It would make sense to initialize the
pointers in kallsyms_lookup_buildid and call there
__bpf_address_lookup() variant. Something like:
static int kallsyms_lookup_buildid(unsigned long addr,
unsigned long *symbolsize,
unsigned long *offset, char **modname,
const unsigned char **modbuildid, char *namebuf)
{
int ret;
if (modname)
*modname = NULL;
if (modbuildid)
*modbuildid = NULL;
namebuf[0] = 0;
[...]
if (!ret)
ret = __bpf_address_lookup(addr, symbolsize, offset, namebuf);
}
As a result bpf_address_lookup() won't have any caller.
And __bpf_address_lookup() would have two callers.
It would make sense to remove bpf_address_lookup() and
rename __bpf_address_lookup() to bpf_address_lookup().
How does that sound?
Would you prefer to do this in one patch or in two steps, please?
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH 2/6] kallsyms: Cleanup code for appending the module buildid
From: Petr Mladek @ 2025-11-07 13:14 UTC (permalink / raw)
To: bot+bpf-ci
Cc: petr.pavlu, rostedt, ast, akpm, kees, daniel, john.fastabend,
mhiramat, mark.rutland, mcgrof, da.gomez, samitolvanen,
linux-kernel, bpf, linux-modules, linux-trace-kernel, andrii,
martin.lau, eddyz87, yonghong.song, clm, ihor.solodrai
In-Reply-To: <451acb410ee1ce42f7fb2da9f3b8162708f40788cb849cc0f50851ad16813349@mail.kernel.org>
On Wed 2025-11-05 14:59:53, bot+bpf-ci@kernel.org wrote:
> > diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
> > index 1e7635864..9455e3bb0 100644
> > --- a/kernel/kallsyms.c
> > +++ b/kernel/kallsyms.c
> > @@ -423,6 +423,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;
> > + }
>
> When ftrace_mod_address_lookup() succeeds in kallsyms_lookup_buildid(),
> it sets *modname but doesn't initialize *modbuildid. This leaves the
> buildid variable uninitialized when __sprint_symbol() calls
> append_buildid().
Just for record. This is a great analyze. This patchset is fixing
this bug in a later patch. ;-)
> Can the check above read uninitialized memory?>
> Looking at kallsyms_lookup_buildid():
> - module_address_lookup() properly initializes both modname and
> modbuildid
> - bpf_address_lookup() sets modname=NULL (so append_buildid isn't
> called)
> - ftrace_mod_address_lookup() sets modname=mod_map->mod->name but has
> no modbuildid parameter
>
> The commit message mentions wanting to catch when lookup functions don't
> handle buildid, but shouldn't kallsyms_lookup_buildid() initialize
> *modbuildid=NULL before calling the lookup functions to avoid undefined
> behavior?
It seems that we are going this way, see
https://lore.kernel.org/all/aQ3vWIqG31BgE4YD@pathway.suse.cz/
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH 3/6] kallsyms/bpf: Set module buildid in bpf_address_lookup()
From: Alexei Starovoitov @ 2025-11-07 17:37 UTC (permalink / raw)
To: Petr Mladek
Cc: Petr Pavlu, Steven Rostedt, Alexei Starovoitov, Andrew Morton,
Kees Cook, Daniel Borkmann, John Fastabend, Masami Hiramatsu,
Mark Rutland, Luis Chamberlain, Daniel Gomez, Sami Tolvanen, LKML,
bpf, linux-modules, linux-trace-kernel
In-Reply-To: <aQ3vWIqG31BgE4YD@pathway.suse.cz>
On Fri, Nov 7, 2025 at 5:08 AM Petr Mladek <pmladek@suse.com> wrote:
>
> On Wed 2025-11-05 18:53:23, Alexei Starovoitov wrote:
> > On Wed, Nov 5, 2025 at 6:24 AM Petr Mladek <pmladek@suse.com> wrote:
> > >
> > > Make bpf_address_lookup() compatible with module_address_lookup()
> > > and clear the pointer to @modbuildid together with @modname.
> > >
> > > It is not strictly needed because __sprint_symbol() reads @modbuildid
> > > only when @modname is set. But better be on the safe side and make
> > > the API more safe.
> > >
> > > Fixes: 9294523e3768 ("module: add printk formats to add module build ID to stacktraces")
> > > Signed-off-by: Petr Mladek <pmladek@suse.com>
> > > ---
> > > include/linux/filter.h | 15 +++++++++++----
> > > kernel/kallsyms.c | 4 ++--
> > > 2 files changed, 13 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/include/linux/filter.h b/include/linux/filter.h
> > > index f5c859b8131a..b7b95840250a 100644
> > > --- a/include/linux/filter.h
> > > +++ b/include/linux/filter.h
> > > @@ -1362,12 +1362,18 @@ 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)
> > > + unsigned long *off, char **modname,
> > > + const unsigned char **modbuildid, char *sym)
> > > {
> > > int ret = __bpf_address_lookup(addr, size, off, sym);
> > >
> > > - if (ret && modname)
> > > - *modname = NULL;
> > > + if (ret) {
> > > + if (modname)
> > > + *modname = NULL;
> > > + if (modbuildid)
> > > + *modbuildid = NULL;
> > > + }
> > > +
> > > return ret;
> > > }
> > >
> > > @@ -1433,7 +1439,8 @@ static inline 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)
> > > + unsigned long *off, char **modname,
> > > + const unsigned char **modbuildid, char *sym)
> > > {
> > > return 0;
> > > }
> > > diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
> > > index 9455e3bb07fc..efb12b077220 100644
> > > --- a/kernel/kallsyms.c
> > > +++ b/kernel/kallsyms.c
> > > @@ -374,8 +374,8 @@ 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,
> > > + modname, modbuildid, namebuf);
> >
> > The initial bpf_address_lookup() 8 years ago was trying
> > to copy paste args and style of kallsyms_lookup().
> > It was odd back then. This change is doubling down on the wrong thing.
> > It's really odd to pass a pointer into bpf_address_lookup()
> > so it zero initializes it.
> > bpf ksyms are in the core kernel. They're never in modules.
> > Just call __bpf_address_lookup() here and remove the wrapper.
>
> I agree that it is ugly. It would make sense to initialize the
> pointers in kallsyms_lookup_buildid and call there
> __bpf_address_lookup() variant. Something like:
>
> static int kallsyms_lookup_buildid(unsigned long addr,
> unsigned long *symbolsize,
> unsigned long *offset, char **modname,
> const unsigned char **modbuildid, char *namebuf)
> {
> int ret;
>
> if (modname)
> *modname = NULL;
> if (modbuildid)
> *modbuildid = NULL;
> namebuf[0] = 0;
> [...]
> if (!ret)
> ret = __bpf_address_lookup(addr, symbolsize, offset, namebuf);
>
> }
Yes. Exactly.
> As a result bpf_address_lookup() won't have any caller.
> And __bpf_address_lookup() would have two callers.
yep
> It would make sense to remove bpf_address_lookup() and
> rename __bpf_address_lookup() to bpf_address_lookup().
yep
> How does that sound?
> Would you prefer to do this in one patch or in two steps, please?
Whichever way is easier. I think it's fine to do it in one go,
though it crosses different subsystems.
^ permalink raw reply
* Re: [PATCH 2/6] kallsyms: Cleanup code for appending the module buildid
From: Alexei Starovoitov @ 2025-11-07 17:40 UTC (permalink / raw)
To: Petr Mladek
Cc: bot+bpf-ci, Petr Pavlu, Steven Rostedt, Alexei Starovoitov,
Andrew Morton, Kees Cook, Daniel Borkmann, John Fastabend,
Masami Hiramatsu, Mark Rutland, Luis R. Rodriguez, Daniel Gomez,
Sami Tolvanen, LKML, bpf, linux-modules, linux-trace-kernel,
Andrii Nakryiko, Martin KaFai Lau, Eduard, Yonghong Song,
Chris Mason, Ihor Solodrai
In-Reply-To: <aQ3w0awU61mrS_AF@pathway.suse.cz>
On Fri, Nov 7, 2025 at 5:15 AM Petr Mladek <pmladek@suse.com> wrote:
>
> On Wed 2025-11-05 14:59:53, bot+bpf-ci@kernel.org wrote:
> > > diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
> > > index 1e7635864..9455e3bb0 100644
> > > --- a/kernel/kallsyms.c
> > > +++ b/kernel/kallsyms.c
> > > @@ -423,6 +423,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;
> > > + }
> >
> > When ftrace_mod_address_lookup() succeeds in kallsyms_lookup_buildid(),
> > it sets *modname but doesn't initialize *modbuildid. This leaves the
> > buildid variable uninitialized when __sprint_symbol() calls
> > append_buildid().
>
> Just for record. This is a great analyze. This patchset is fixing
> this bug in a later patch. ;-)
Currently AI analyses one patch at a time and comments on what it
understands the way humans would do if they read and comment
as they go.
Teaching AI to understand the whole series is on todo list.
Chris may comment on how feasible that is.
^ permalink raw reply
* Re: [PATCH v7 0/8] lib/crypto: Add ML-DSA signing
From: Stefan Berger @ 2025-11-07 18:32 UTC (permalink / raw)
To: David Howells, Herbert Xu
Cc: Eric Biggers, 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: <20251106174456.31818-1-dhowells@redhat.com>
On 11/6/25 12:44 PM, David Howells wrote:
> Hi Herbert, Eric, et al.,
>
> Building on the SHA-3 lib-crypto patches now in Eric's tree, here's a set of
> patches does the following:
>
> (1) Add SHAKE-256 crypto_sig support, generating 32-byte fixed output. The
> XOF features aren't available through this. SHAKE-128 crypto_sig support
> isn't required for ML-DSA, so I haven't implemented that at this time.
>
> (2) Add ML-DSA signature verification code, extracted from Stephan Mueller's
> Leancrypto project. It is accessed through crypto_sig.
>
> (3) Add a kunit test in three installments (due to size) to add some
> testing for the three different levels of ML-DSA (44, 65 and 87).
>
> (4) Modify PKCS#7 support to allow kernel module signatures to carry
> authenticatedAttributes as OpenSSL refuses to let them be opted out of
> for ML-DSA (CMS_NOATTR). This adds an extra digest calculation to the
> process.
>
> (5) Modify PKCS#7 to pass the authenticatedAttributes directly to the
> ML-DSA algorithm rather than passing over a digest as is done with RSA
> as ML-DSA wants to do its own hashing and will add other stuff into
> the hash. We could use hashML-DSA or an external mu instead, but they
> aren't standardised for CMS yet.
>
> (6) Add support to the PKCS#7 and X.509 parsers for ML-DSA.
>
> (7) Modify sign-file to handle OpenSSL not permitting CMS_NOATTR with
> ML-DSA.
> > (8) Allow SHA-3 algorithms, including SHAKE256, to be used for
the message
> digest and add ML-DSA to the choice of algorithm with which to sign.
Hi David,
if you are interested in picking patches from my effort in this
direction, let me know. I have a test suite in user space at
https://github.com/stefanberger/mldsa-testing
User space patches interfacing with the kernel (prefix 'keyctl:') are in
this series here:
https://github.com/stefanberger/linux-ima-namespaces/commits/mldsa.10312025/
Either way, great work!
>
> With that, ML-DSA signing appears to work.
>
> This is based on Eric's libcrypto-next branch.
>
> The patches can also be found here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-pqc
>
> David
>
> Changes
> =======
> ver #7)
> - Rebased on Eric's tree as that now contains all the necessary SHA-3
> infrastructure and drop the SHA-3 patches from here.
> - Added a minimal patch to provide shake256 support for crypto_sig.
> - Got rid of the memory allocation wrappers.
> - Removed the ML-DSA keypair generation code and the signing code, leaving
> only the signature verification code.
> - Removed the secret key handling code.
> - Removed the secret keys from the kunit tests and the signing testing.
> - Removed some unused bits from the ML-DSA code.
> - Downgraded the kdoc comments to ordinary comments, but keep the markup
> for easier comparison to Leancrypto.
>
> ver #6)
> - Added a patch to make the jitterentropy RNG use lib/sha3.
> - Added back the crypto/sha3_generic changes.
> - Added ML-DSA implementation (still needs more cleanup).
> - Added kunit test for ML-DSA.
> - Modified PKCS#7 to accommodate ML-DSA.
> - Modified PKCS#7 and X.509 to allow ML-DSA to be specified and used.
> - Modified sign-file to not use CMS_NOATTR with ML-DSA.
> - Allowed SHA3 and SHAKE* algorithms for module signing default.
> - Allowed ML-DSA-{44,65,87} to be selected as the module signing default.
>
> ver #5)
> - Fix gen-hash-testvecs.py to correctly handle algo names that contain a
> dash.
> - Fix gen-hash-testvecs.py to not generate HMAC for SHA3-* or SHAKE* as
> these don't currently have HMAC variants implemented.
> - Fix algo names to be correct.
> - Fix kunit module description as it now tests all SHA3 variants.
>
> ver #4)
> - Fix a couple of arm64 build problems.
> - Doc fixes:
> - Fix the description of the algorithm to be closer to the NIST spec's
> terminology.
> - Don't talk of finialising the context for XOFs.
> - Don't say "Return: None".
> - Declare the "Context" to be "Any context" and make no mention of the
> fact that it might use the FPU.
> - Change "initialise" to "initialize".
> - Don't warn that the context is relatively large for stack use.
> - Use size_t for size parameters/variables.
> - Make the module_exit unconditional.
> - Dropped the crypto/ dir-affecting patches for the moment.
>
> ver #3)
> - Renamed conflicting arm64 functions.
> - Made a separate wrapper API for each algorithm in the family.
> - Removed sha3_init(), sha3_reinit() and sha3_final().
> - Removed sha3_ctx::digest_size.
> - Renamed sha3_ctx::partial to sha3_ctx::absorb_offset.
> - Refer to the output of SHAKE* as "output" not "digest".
> - Moved the Iota transform into the one-round function.
> - Made sha3_update() warn if called after sha3_squeeze().
> - Simplified the module-load test to not do update after squeeze.
> - Added Return: and Context: kdoc statements and expanded the kdoc
> headers.
> - Added an API description document.
> - Overhauled the kunit tests.
> - Only have one kunit test.
> - Only call the general hash tester on one algo.
> - Add separate simple cursory checks for the other algos.
> - Add resqueezing tests.
> - Add some NIST example tests.
> - Changed crypto/sha3_generic to use this
> - Added SHAKE128/256 to crypto/sha3_generic and crypto/testmgr
> - Folded struct sha3_state into struct sha3_ctx.
>
> ver #2)
> - Simplify the endianness handling.
> - Rename sha3_final() to sha3_squeeze() and don't clear the context at the
> end as it's permitted to continue calling sha3_final() to extract
> continuations of the digest (needed by ML-DSA).
> - Don't reapply the end marker to the hash state in continuation
> sha3_squeeze() unless sha3_update() gets called again (needed by
> ML-DSA).
> - Give sha3_squeeze() the amount of digest to produce as a parameter
> rather than using ctx->digest_size and don't return the amount digested.
> - Reimplement sha3_final() as a wrapper around sha3_squeeze() that
> extracts ctx->digest_size amount of digest and then zeroes out the
> context. The latter is necessary to avoid upsetting
> hash-test-template.h.
> - Provide a sha3_reinit() function to clear the state, but to leave the
> parameters that indicate the hash properties unaffected, allowing for
> reuse.
> - Provide a sha3_set_digestsize() function to change the size of the
> digest to be extracted by sha3_final(). sha3_squeeze() takes a
> parameter for this instead.
> - Don't pass the digest size as a parameter to shake128/256_init() but
> rather default to 128/256 bits as per the function name.
> - Provide a sha3_clear() function to zero out the context.
>
> David Howells (8):
> crypto: Add support for shake256 through crypto_shash
> crypto: Add ML-DSA/Dilithium verify support
> crypto: Add ML-DSA-44 pure rejection test vectors as a kunit test
> crypto: Add ML-DSA-65 pure rejection test vectors as a kunit test
> crypto: Add ML-DSA-87 pure rejection test vectors as a kunit test
> pkcs7: Allow the signing algo to calculate the digest itself
> pkcs7, x509: Add ML-DSA support
> modsign: Enable ML-DSA module signing
>
> Documentation/admin-guide/module-signing.rst | 15 +-
> certs/Kconfig | 24 +
> certs/Makefile | 3 +
> crypto/Kconfig | 1 +
> crypto/Makefile | 1 +
> crypto/asymmetric_keys/pkcs7_parser.c | 19 +-
> crypto/asymmetric_keys/pkcs7_verify.c | 52 +-
> crypto/asymmetric_keys/public_key.c | 7 +
> crypto/asymmetric_keys/x509_cert_parser.c | 24 +
> crypto/ml_dsa/Kconfig | 32 +
> crypto/ml_dsa/Makefile | 20 +
> crypto/ml_dsa/dilithium.h | 547 ++
> crypto/ml_dsa/dilithium_44.c | 33 +
> crypto/ml_dsa/dilithium_44.h | 282 +
> crypto/ml_dsa/dilithium_65.c | 33 +
> crypto/ml_dsa/dilithium_65.h | 282 +
> crypto/ml_dsa/dilithium_87.c | 33 +
> crypto/ml_dsa/dilithium_87.h | 282 +
> crypto/ml_dsa/dilithium_api.c | 429 ++
> crypto/ml_dsa/dilithium_debug.h | 49 +
> crypto/ml_dsa/dilithium_ntt.c | 89 +
> crypto/ml_dsa/dilithium_ntt.h | 35 +
> crypto/ml_dsa/dilithium_pack.h | 119 +
> crypto/ml_dsa/dilithium_poly.c | 377 +
> crypto/ml_dsa/dilithium_poly.h | 181 +
> crypto/ml_dsa/dilithium_poly_c.h | 141 +
> crypto/ml_dsa/dilithium_poly_common.h | 35 +
> crypto/ml_dsa/dilithium_polyvec.h | 343 +
> crypto/ml_dsa/dilithium_polyvec_c.h | 81 +
> .../dilithium_pure_rejection_vectors_44.h | 489 ++
> .../dilithium_pure_rejection_vectors_65.h | 4741 ++++++++++++
> .../dilithium_pure_rejection_vectors_87.h | 6456 +++++++++++++++++
> crypto/ml_dsa/dilithium_reduce.h | 85 +
> crypto/ml_dsa/dilithium_rounding.c | 128 +
> crypto/ml_dsa/dilithium_selftest.c | 142 +
> crypto/ml_dsa/dilithium_service_helpers.h | 99 +
> crypto/ml_dsa/dilithium_sig.c | 334 +
> crypto/ml_dsa/dilithium_signature_c.c | 102 +
> crypto/ml_dsa/dilithium_signature_c.h | 37 +
> crypto/ml_dsa/dilithium_signature_helper.c | 97 +
> crypto/ml_dsa/dilithium_signature_impl.h | 370 +
> crypto/ml_dsa/dilithium_type.h | 102 +
> crypto/ml_dsa/dilithium_zetas.c | 67 +
> crypto/ml_dsa/signature_domain_separation.c | 203 +
> crypto/ml_dsa/signature_domain_separation.h | 30 +
> crypto/sha3.c | 42 +
> include/crypto/public_key.h | 1 +
> include/linux/oid_registry.h | 5 +
> kernel/module/Kconfig | 5 +
> scripts/sign-file.c | 26 +-
> 50 files changed, 17094 insertions(+), 36 deletions(-)
> create mode 100644 crypto/ml_dsa/Kconfig
> create mode 100644 crypto/ml_dsa/Makefile
> create mode 100644 crypto/ml_dsa/dilithium.h
> create mode 100644 crypto/ml_dsa/dilithium_44.c
> create mode 100644 crypto/ml_dsa/dilithium_44.h
> create mode 100644 crypto/ml_dsa/dilithium_65.c
> create mode 100644 crypto/ml_dsa/dilithium_65.h
> create mode 100644 crypto/ml_dsa/dilithium_87.c
> create mode 100644 crypto/ml_dsa/dilithium_87.h
> create mode 100644 crypto/ml_dsa/dilithium_api.c
> create mode 100644 crypto/ml_dsa/dilithium_debug.h
> create mode 100644 crypto/ml_dsa/dilithium_ntt.c
> create mode 100644 crypto/ml_dsa/dilithium_ntt.h
> create mode 100644 crypto/ml_dsa/dilithium_pack.h
> create mode 100644 crypto/ml_dsa/dilithium_poly.c
> create mode 100644 crypto/ml_dsa/dilithium_poly.h
> create mode 100644 crypto/ml_dsa/dilithium_poly_c.h
> create mode 100644 crypto/ml_dsa/dilithium_poly_common.h
> create mode 100644 crypto/ml_dsa/dilithium_polyvec.h
> create mode 100644 crypto/ml_dsa/dilithium_polyvec_c.h
> create mode 100644 crypto/ml_dsa/dilithium_pure_rejection_vectors_44.h
> create mode 100644 crypto/ml_dsa/dilithium_pure_rejection_vectors_65.h
> create mode 100644 crypto/ml_dsa/dilithium_pure_rejection_vectors_87.h
> create mode 100644 crypto/ml_dsa/dilithium_reduce.h
> create mode 100644 crypto/ml_dsa/dilithium_rounding.c
> create mode 100644 crypto/ml_dsa/dilithium_selftest.c
> create mode 100644 crypto/ml_dsa/dilithium_service_helpers.h
> create mode 100644 crypto/ml_dsa/dilithium_sig.c
> create mode 100644 crypto/ml_dsa/dilithium_signature_c.c
> create mode 100644 crypto/ml_dsa/dilithium_signature_c.h
> create mode 100644 crypto/ml_dsa/dilithium_signature_helper.c
> create mode 100644 crypto/ml_dsa/dilithium_signature_impl.h
> create mode 100644 crypto/ml_dsa/dilithium_type.h
> create mode 100644 crypto/ml_dsa/dilithium_zetas.c
> create mode 100644 crypto/ml_dsa/signature_domain_separation.c
> create mode 100644 crypto/ml_dsa/signature_domain_separation.h
>
>
^ permalink raw reply
* Re: [PATCH v2] lsm,ima: new LSM hook security_kernel_module_read_file to access decompressed kernel module
From: Mimi Zohar @ 2025-11-07 19:28 UTC (permalink / raw)
To: Coiby Xu
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: <b9eb78105115a00731b3677a5f3a39d5dde4d2ec.camel@linux.ibm.com>
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
--
thanks,
Mimi
^ permalink raw reply
* Re: [PATCH 4/6] kallsyms/ftrace: Set module buildid in ftrace_mod_address_lookup()
From: Aaron Tomlin @ 2025-11-07 22:49 UTC (permalink / raw)
To: Petr Mladek
Cc: Petr Pavlu, Steven Rostedt, Alexei Starovoitov, Andrew Morton,
Kees Cook, Daniel Borkmann, John Fastabend, Masami Hiramatsu,
Mark Rutland, Luis Chamberlain, Daniel Gomez, Sami Tolvanen,
linux-kernel, bpf, linux-modules, linux-trace-kernel
In-Reply-To: <20251105142319.1139183-5-pmladek@suse.com>
On Wed, Nov 05, 2025 at 03:23:16PM +0100, Petr Mladek wrote:
> __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")
> 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 efb12b077220..71868a76e9a1 100644
> --- a/kernel/kallsyms.c
> +++ b/kernel/kallsyms.c
> @@ -378,8 +378,8 @@ static int kallsyms_lookup_buildid(unsigned long addr,
> modname, modbuildid, 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
>
>
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
--
Aaron Tomlin
^ permalink raw reply
* Re: [PATCH 5/6] kallsyms: Clean up @namebuf initialization in kallsyms_lookup_buildid()
From: Aaron Tomlin @ 2025-11-07 22:50 UTC (permalink / raw)
To: Petr Mladek
Cc: Petr Pavlu, Steven Rostedt, Alexei Starovoitov, Andrew Morton,
Kees Cook, Daniel Borkmann, John Fastabend, Masami Hiramatsu,
Mark Rutland, Luis Chamberlain, Daniel Gomez, Sami Tolvanen,
linux-kernel, bpf, linux-modules, linux-trace-kernel
In-Reply-To: <20251105142319.1139183-6-pmladek@suse.com>
On Wed, Nov 05, 2025 at 03:23:17PM +0100, Petr Mladek wrote:
> 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.
>
> 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 71868a76e9a1..ff7017337535 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
>
>
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
--
Aaron Tomlin
^ permalink raw reply
* Re: [PATCH 6/6] kallsyms: Prevent module removal when printing module name and buildid
From: Aaron Tomlin @ 2025-11-08 0:36 UTC (permalink / raw)
To: Petr Mladek
Cc: Petr Pavlu, Steven Rostedt, Alexei Starovoitov, Andrew Morton,
Kees Cook, Daniel Borkmann, John Fastabend, Masami Hiramatsu,
Mark Rutland, Luis Chamberlain, Daniel Gomez, Sami Tolvanen,
linux-kernel, bpf, linux-modules, linux-trace-kernel
In-Reply-To: <20251105142319.1139183-7-pmladek@suse.com>
On Wed, Nov 05, 2025 at 03:23:18PM +0100, Petr Mladek wrote:
> 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().
>
> 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 ff7017337535..1fda06b6638c 100644
> --- a/kernel/kallsyms.c
> +++ b/kernel/kallsyms.c
> @@ -468,6 +468,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
>
>
Hi Petr,
If I am not mistaken, this is handled safely within the context of
module_address_lookup() since f01369239293e ("module: Use RCU in
find_kallsyms_symbol()."), no?
Kind regards,
--
Aaron Tomlin
^ permalink raw reply
* Re: Only rust/bindings.o build fail on rust-1.91.0
From: Miguel Ojeda @ 2025-11-08 1:41 UTC (permalink / raw)
To: Sami Tolvanen
Cc: Haiyue Wang, rust-for-linux, Miguel Ojeda, linux-modules,
Linux Kbuild mailing list
In-Reply-To: <CANiq72mw66ADx7LoUuqY6h9KCU=uFzcNQXZ21kMP7jBjCyyaHQ@mail.gmail.com>
On Thu, Nov 6, 2025 at 6:54 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> Bisecting nightlies, it seemed to happen between:
>
> rustc 1.91.0-nightly (12eb345e5 2025-09-07)
> rustc 1.91.0-nightly (9c27f27ea 2025-09-08)
Ok, for reference, it was upstream's ab91a63d403b ("Ignore intrinsic
calls in cross-crate-inlining cost model"): the object file stops
containing DWARF debug information because the `Default`
implementations contained `write_bytes()` calls which are now ignored
in that cost model and so everything is essentially as if `#[inline]`.
If one generates the bindings without the `Debug` impls, indeed the
file stops containing DWARF even in Rust 1.90.0.
For the moment, we can just skip `gendwarfksyms` starting with Rust
1.91.0 (sending a quick patch for that), but it may be a bit brittle
in that new versions could again re-introduce some symbols that get
exported from that one etc.
Sami, would it make sense to "auto-skip" in `gendwarfksyms` itself if
an object file does not have anything interesting and then remove that
from the `Makefile`?
Thanks!
Cheers,
Miguel
^ permalink raw reply
* [PATCH] rust: kbuild: skip gendwarfksyms in `bindings.o` for Rust >= 1.91.0
From: Miguel Ojeda @ 2025-11-08 1:42 UTC (permalink / raw)
To: Sami Tolvanen, Miguel Ojeda, Alex Gaynor
Cc: 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
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?
For the moment, conditionally skip `gendwarfksyms` for Rust >= 1.91.0.
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/
Link: https://github.com/rust-lang/rust/commit/ab91a63d403b0105cacd72809cd292a72984ed99 [1]
Link: https://github.com/rust-lang/rust/pull/145910 [2]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
rust/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/rust/Makefile b/rust/Makefile
index 3e545c1a0ff4..269bf7cf5b97 100644
--- a/rust/Makefile
+++ b/rust/Makefile
@@ -543,6 +543,7 @@ $(obj)/ffi.o: private skip_gendwarfksyms = 1
$(obj)/ffi.o: $(src)/ffi.rs $(obj)/compiler_builtins.o FORCE
+$(call if_changed_rule,rustc_library)
+$(obj)/bindings.o: private skip_gendwarfksyms := $(if $(call rustc-min-version,109100),1)
$(obj)/bindings.o: private rustc_target_flags = --extern ffi --extern pin_init
$(obj)/bindings.o: $(src)/bindings/lib.rs \
$(obj)/ffi.o \
base-commit: dc77806cf3b4788d328fddf245e86c5b529f31a2
--
2.51.2
^ permalink raw reply related
* Re: [PATCH] rust: kbuild: skip gendwarfksyms in `bindings.o` for Rust >= 1.91.0
From: Miguel Ojeda @ 2025-11-08 2:30 UTC (permalink / raw)
To: Sami Tolvanen
Cc: 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, Miguel Ojeda
In-Reply-To: <20251108014246.689509-1-ojeda@kernel.org>
On Sat, Nov 8, 2025 at 2:44 AM Miguel Ojeda <ojeda@kernel.org> wrote:
>
> note that `CLIPPY=1` does not reproduce it
And obviously this means we have to special case this one too...
$(obj)/bindings.o: private skip_gendwarfksyms := $(if $(call
rustc-min-version,109100),$(if $(KBUILD_CLIPPY),,1))
There may be other cases that disable the optimization or similar,
plus we may have other small crates in the future that could also
suffer from this, so it may be best to simply force to generate the
DWARF with a dummy symbol from that crate for the time being as the
fix:
#[expect(unused)]
static DUMMY_SYMBOL_FOR_DWARF_DEBUGINFO_GENERATION_FOR_GENDWARFKSYMS:
() = ();
With `#[no_mangle]` may be more reliable and it also gives an actual
exported symbol.
And then later do something in the `cmd` command itself or teaching
`genkallksyms` to auto-skip in cases like this.
What do you think?
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH] rust: kbuild: skip gendwarfksyms in `bindings.o` for Rust >= 1.91.0
From: Miguel Ojeda @ 2025-11-08 2:37 UTC (permalink / raw)
To: Sami Tolvanen
Cc: 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, Miguel Ojeda
In-Reply-To: <CANiq72nKC5r24VHAp9oUPR1HVPqT+=0ab9N0w6GqTF-kJOeiSw@mail.gmail.com>
On Sat, Nov 8, 2025 at 3:30 AM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> With `#[no_mangle]` may be more reliable and it also gives an actual
> exported symbol.
Or `#[used]` to keep it mangled since we don't care.
Cheers,
Miguel
^ permalink raw reply
* Re: Only rust/bindings.o build fail on rust-1.91.0
From: Sami Tolvanen @ 2025-11-08 2:39 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Haiyue Wang, rust-for-linux, Miguel Ojeda, linux-modules,
Linux Kbuild mailing list
In-Reply-To: <CANiq72=OFO8fBpJ6xvGunYrx5hXfcjQJ=YDqFxtMPWDzfzwpKw@mail.gmail.com>
On Fri, Nov 7, 2025 at 5:42 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Thu, Nov 6, 2025 at 6:54 PM Miguel Ojeda
> <miguel.ojeda.sandonis@gmail.com> wrote:
> >
> > Bisecting nightlies, it seemed to happen between:
> >
> > rustc 1.91.0-nightly (12eb345e5 2025-09-07)
> > rustc 1.91.0-nightly (9c27f27ea 2025-09-08)
>
> Ok, for reference, it was upstream's ab91a63d403b ("Ignore intrinsic
> calls in cross-crate-inlining cost model"): the object file stops
> containing DWARF debug information because the `Default`
> implementations contained `write_bytes()` calls which are now ignored
> in that cost model and so everything is essentially as if `#[inline]`.
>
> If one generates the bindings without the `Debug` impls, indeed the
> file stops containing DWARF even in Rust 1.90.0.
>
> For the moment, we can just skip `gendwarfksyms` starting with Rust
> 1.91.0 (sending a quick patch for that), but it may be a bit brittle
> in that new versions could again re-introduce some symbols that get
> exported from that one etc.
Technically speaking, bindings.o still exports ~1500 symbols even with
newer rustc versions. If we don't actually expect modules to use these
symbols, the correct solution is to not export them. Otherwise,
modules that depend on these symbols will nevertheless fail to load
with modversions.
> Sami, would it make sense to "auto-skip" in `gendwarfksyms` itself if
> an object file does not have anything interesting and then remove that
> from the `Makefile`?
I'm not sure it makes sense to silently export unusable symbols. I
feel like we should either ensure there's debugging information for
these symbols, or just not export them.
Sami
^ permalink raw reply
* Re: [PATCH] rust: kbuild: skip gendwarfksyms in `bindings.o` for Rust >= 1.91.0
From: Sami Tolvanen @ 2025-11-08 2:49 UTC (permalink / raw)
To: Miguel Ojeda
Cc: 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, Miguel Ojeda
In-Reply-To: <CANiq72nKC5r24VHAp9oUPR1HVPqT+=0ab9N0w6GqTF-kJOeiSw@mail.gmail.com>
On Fri, Nov 7, 2025 at 6:31 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Sat, Nov 8, 2025 at 2:44 AM Miguel Ojeda <ojeda@kernel.org> wrote:
> >
> > note that `CLIPPY=1` does not reproduce it
>
> And obviously this means we have to special case this one too...
>
> $(obj)/bindings.o: private skip_gendwarfksyms := $(if $(call
> rustc-min-version,109100),$(if $(KBUILD_CLIPPY),,1))
>
> There may be other cases that disable the optimization or similar,
> plus we may have other small crates in the future that could also
> suffer from this, so it may be best to simply force to generate the
> DWARF with a dummy symbol from that crate for the time being as the
> fix:
>
> #[expect(unused)]
> static DUMMY_SYMBOL_FOR_DWARF_DEBUGINFO_GENERATION_FOR_GENDWARFKSYMS:
> () = ();
This looks reasonable to me, and indeed seems to fix the problem.
> And then later do something in the `cmd` command itself or teaching
> `genkallksyms` to auto-skip in cases like this.
>
> What do you think?
Like I mentioned in the other thread, we ideally wouldn't silently
skip symbol versioning because the exported symbols won't be usable in
this case.
Sami
^ permalink raw reply
* Re: Only rust/bindings.o build fail on rust-1.91.0
From: Miguel Ojeda @ 2025-11-08 3:51 UTC (permalink / raw)
To: Sami Tolvanen
Cc: Haiyue Wang, rust-for-linux, Miguel Ojeda, linux-modules,
Linux Kbuild mailing list
In-Reply-To: <CABCJKue1xeY7CGHScG04PdHT6TOPgsOpZVKWwgzO65qwAcbEJg@mail.gmail.com>
On Sat, Nov 8, 2025 at 3:40 AM Sami Tolvanen <samitolvanen@google.com> wrote:
>
> Technically speaking, bindings.o still exports ~1500 symbols even with
> newer rustc versions.
What do you mean?
Cheers,
Miguel
^ permalink raw reply
* Re: Only rust/bindings.o build fail on rust-1.91.0
From: Miguel Ojeda @ 2025-11-08 4:04 UTC (permalink / raw)
To: Sami Tolvanen
Cc: Haiyue Wang, rust-for-linux, Miguel Ojeda, linux-modules,
Linux Kbuild mailing list
In-Reply-To: <CANiq72ncHgjjJ_c2fdTgOO9LxmmotRS8S6pwyckLmPJG_4GPNg@mail.gmail.com>
On Sat, Nov 8, 2025 at 4:51 AM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> What do you mean?
Do you mean in some cases? i.e. like with `CLIPPY=1`?
Cheers,
Miguel
^ permalink raw reply
* Re: Only rust/bindings.o build fail on rust-1.91.0
From: Sami Tolvanen @ 2025-11-08 4:42 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Haiyue Wang, rust-for-linux, Miguel Ojeda, linux-modules,
Linux Kbuild mailing list
In-Reply-To: <CANiq72kcRsTWPhQVJ18P6RUxL=+c1Z8BJkyK_kRR8EBmmH+cWg@mail.gmail.com>
On Sat, Nov 08, 2025 at 05:04:06AM +0100, Miguel Ojeda wrote:
> On Sat, Nov 8, 2025 at 4:51 AM Miguel Ojeda
> <miguel.ojeda.sandonis@gmail.com> wrote:
> >
> > What do you mean?
>
> Do you mean in some cases? i.e. like with `CLIPPY=1`?
Ah, nevermind. I was looking at a stale object file. If there are no
exports, we should obviously skip gendwarfksyms.
For C objects, we use nm to check for __export_symbol_* symbols
before we attempt to generate symbol versions (see gen_symversions
in scripts/Makefile.build). We could do something similar for Rust
objects too, or just bail out early in gendwarfksyms if it's passed an
empty symbol list.
The trivial patch below should fix the issue.
Sami
---
From d1a4096cd328beae3323a1beb207c7cb5e770770 Mon Sep 17 00:00:00 2001
From: Sami Tolvanen <samitolvanen@google.com>
Date: Sat, 8 Nov 2025 04:26:10 +0000
Subject: [PATCH] gendwarfksyms: Skip files with no exports
Don't attempt to process files if we have no symbol versions to
calculate.
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
scripts/gendwarfksyms/gendwarfksyms.c | 3 ++-
scripts/gendwarfksyms/gendwarfksyms.h | 2 +-
scripts/gendwarfksyms/symbols.c | 4 +++-
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/scripts/gendwarfksyms/gendwarfksyms.c b/scripts/gendwarfksyms/gendwarfksyms.c
index 08ae61eb327e..f5203d1640ee 100644
--- a/scripts/gendwarfksyms/gendwarfksyms.c
+++ b/scripts/gendwarfksyms/gendwarfksyms.c
@@ -138,7 +138,8 @@ int main(int argc, char **argv)
error("no input files?");
}
- symbol_read_exports(stdin);
+ if (!symbol_read_exports(stdin))
+ return 0;
if (symtypes_file) {
symfile = fopen(symtypes_file, "w");
diff --git a/scripts/gendwarfksyms/gendwarfksyms.h b/scripts/gendwarfksyms/gendwarfksyms.h
index d9c06d2cb1df..32cec8f7695a 100644
--- a/scripts/gendwarfksyms/gendwarfksyms.h
+++ b/scripts/gendwarfksyms/gendwarfksyms.h
@@ -123,7 +123,7 @@ struct symbol {
typedef void (*symbol_callback_t)(struct symbol *, void *arg);
bool is_symbol_ptr(const char *name);
-void symbol_read_exports(FILE *file);
+int symbol_read_exports(FILE *file);
void symbol_read_symtab(int fd);
struct symbol *symbol_get(const char *name);
void symbol_set_ptr(struct symbol *sym, Dwarf_Die *ptr);
diff --git a/scripts/gendwarfksyms/symbols.c b/scripts/gendwarfksyms/symbols.c
index 35ed594f0749..ecddcb5ffcdf 100644
--- a/scripts/gendwarfksyms/symbols.c
+++ b/scripts/gendwarfksyms/symbols.c
@@ -128,7 +128,7 @@ static bool is_exported(const char *name)
return for_each(name, NULL, NULL) > 0;
}
-void symbol_read_exports(FILE *file)
+int symbol_read_exports(FILE *file)
{
struct symbol *sym;
char *line = NULL;
@@ -159,6 +159,8 @@ void symbol_read_exports(FILE *file)
free(line);
debug("%d exported symbols", nsym);
+
+ return nsym;
}
static void get_symbol(struct symbol *sym, void *arg)
--
2.51.2.1041.gc1ab5b90ca-goog
^ permalink raw reply related
* Re: Only rust/bindings.o build fail on rust-1.91.0
From: Miguel Ojeda @ 2025-11-08 5:08 UTC (permalink / raw)
To: Sami Tolvanen
Cc: Haiyue Wang, rust-for-linux, Miguel Ojeda, linux-modules,
Linux Kbuild mailing list
In-Reply-To: <20251108044206.GA3038215@google.com>
On Sat, Nov 8, 2025 at 5:42 AM Sami Tolvanen <samitolvanen@google.com> wrote:
>
> Ah, nevermind. I was looking at a stale object file. If there are no
> exports, we should obviously skip gendwarfksyms.
Ah, good, thanks, I was wondering if I was missing something.
> For C objects, we use nm to check for __export_symbol_* symbols
> before we attempt to generate symbol versions (see gen_symversions
> in scripts/Makefile.build). We could do something similar for Rust
> objects too, or just bail out early in gendwarfksyms if it's passed an
> empty symbol list.
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).
Cheers,
Miguel
^ permalink raw reply
* Re: Only rust/bindings.o build fail on rust-1.91.0
From: Miguel Ojeda @ 2025-11-08 5:10 UTC (permalink / raw)
To: Sami Tolvanen
Cc: Haiyue Wang, rust-for-linux, Miguel Ojeda, linux-modules,
Linux Kbuild mailing list
In-Reply-To: <CABCJKue1xeY7CGHScG04PdHT6TOPgsOpZVKWwgzO65qwAcbEJg@mail.gmail.com>
On Sat, Nov 8, 2025 at 3:40 AM Sami Tolvanen <samitolvanen@google.com> wrote:
>
> I'm not sure it makes sense to silently export unusable symbols. I
> feel like we should either ensure there's debugging information for
> these symbols, or just not export them.
(Now that I saw your other reply and things are clearer, replying here
as well for completeness)
No, I didn't mean to silently export, but rather to avoid failing due
to missing DWARF if there is nothing to do for that object file
because there are no exports. That is, what we manually do now with
some of the `skip_gendwarfksyms`, but dynamically, which unties us
from the inlining decisions of `rustc` which could hit us in e.g.
small crates in the future or edge cases like the bindings one.
Cheers,
Miguel
^ 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