* Re: [PATCH v18 0/7] rust: extend `module!` macro with integer parameter support
From: Uwe Kleine-König @ 2025-11-02 9:56 UTC (permalink / raw)
To: Daniel Gomez
Cc: Andreas Hindborg, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
Björn Roy Baron, Alice Ryhl, Masahiro Yamada,
Nathan Chancellor, Luis Chamberlain, Danilo Krummrich,
Benno Lossin, Nicolas Schier, Michal Wilczynski, Trevor Gross,
Adam Bratschi-Kaye, rust-for-linux, linux-kernel, linux-kbuild,
Petr Pavlu, Sami Tolvanen, Daniel Gomez, Simona Vetter, Greg KH,
Fiona Behrens, Daniel Almeida, linux-modules, Stephen Rothwell,
linux-next
In-Reply-To: <49af6d76-bcb7-4343-8903-390040e2c49b@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 8479 bytes --]
Hello Daniel,
[Adding Stephen and linux-next to Cc]
On Sat, Nov 01, 2025 at 10:39:08PM +0100, Daniel Gomez wrote:
> On 24/09/2025 14.39, Andreas Hindborg wrote:
> > Extend the `module!` macro with support module parameters. Also add some
> > string to integer parsing functions.
> >
> > Based on the original module parameter support by Miguel [1],
> > later extended and generalized by Adam for more types [2][3].
> > Originally tracked at [4].
> >
> > Link: https://github.com/Rust-for-Linux/linux/pull/7 [1]
> > Link: https://github.com/Rust-for-Linux/linux/pull/82 [2]
> > Link: https://github.com/Rust-for-Linux/linux/pull/87 [3]
> > Link: https://github.com/Rust-for-Linux/linux/issues/11 [4]
> > Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
>
> I tested this series with rust_minimal module. They LGTM,
>
> Tested-by: Daniel Gomez <da.gomez@samsung.com>
>
> The patches did not apply cleanly to v6.18-rc3, at least not when using b4.
> However, when applying them to the base commit and then rebasing onto v6.18-rc3,
> I didn't see any conflicts.
I don't know how you use b4, but
git checkout v6.18-rc3
b4 am -3 49af6d76-bcb7-4343-8903-390040e2c49b@kernel.org
git am -3 ./v18_20250924_a_hindborg_rust_extend_module_macro_with_integer_parameter_support.mbx
works fine on my end. Using `-3` should have the same effect as applying
the series on top of the original base and rebase it.
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git rebase/20250924-module-params-v3-v18-0-bf512c35d910@kernel.org
git range-diff FETCH_HEAD...HEAD
confirms that.
> I've created a temporary branch with this rebase here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git/log/?h=rebase/20250924-module-params-v3-v18-0-bf512c35d910@kernel.org
>
> Can you take a look when you can? I'll merge this shortly after checking with
> Uwe, as there are some minor conflicts with his tree.
>
> + Uwe
>
> These are the conflicts I see when merging the patch series from Michal [1]
> (Introduce import_ns support for Rust). I believe these are trivial things that
> we will get notified from linux-next merging. But let me know what you think as
> you have requested in that thread.
>
> [1] Link: https://lore.kernel.org/all/20251028-pwm_fixes-v1-0-25a532d31998@samsung.com/
Yeah, I expect that Stephen will highlight the conflicts, but I prefer
to not be surprised by that and consider linux-next more a fallback
security net that I don't want to use. I like it to be the other way
round and tell Stephen about conflicts to expect :-)
> ...
> Applying: rust: macros: Add support for 'imports_ns' to module!
> Patch failed at 0008 rust: macros: Add support for 'imports_ns' to module!
> error: patch failed: rust/macros/module.rs:98
> error: rust/macros/module.rs: patch does not apply
> hint: Use 'git am --show-current-patch=diff' to see the failed patch
> hint: When you have resolved this problem, run "git am --continue".
> hint: If you prefer to skip this patch, run "git am --skip" instead.
> hint: To restore the original branch and stop patching, run "git am --abort".
> hint: Disable this message with "git config set advice.mergeConflict false"
>
> git am --show-current-patch=diff
That command shows the patch to apply, but not the conflict, let alone
your resolution.
> ---
> rust/macros/module.rs | 8 ++++++++
> 1 file changed, 8 insertions(+)
> ---
> rust/macros/module.rs | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/rust/macros/module.rs b/rust/macros/module.rs
> index 5ee54a00c0b65699596e660b2d4d60e64be2a50c..408cd115487514c8be79724d901c676435696376 100644
> --- a/rust/macros/module.rs
> +++ b/rust/macros/module.rs
> @@ -98,6 +98,7 @@ struct ModuleInfo {
> description: Option<String>,
> alias: Option<Vec<String>>,
> firmware: Option<Vec<String>>,
> + imports_ns: Option<Vec<String>>,
> }
So here the addition of `params` is missing.
> [...]
When I merge your branch mentioned above with my pwm/for-next and
resolve the merge conflicts, the resolution looks as follows. The only
non-trivial thing is that
if let Some(imports) = info.imports_ns {
now needs a & for `info`.
Best regards
Uwe
diff --cc rust/macros/module.rs
index d62e9c1e2a89,408cd1154875..000000000000
--- a/rust/macros/module.rs
+++ b/rust/macros/module.rs
@@@ -205,50 -98,7 +205,51 @@@ struct ModuleInfo
description: Option<String>,
alias: Option<Vec<String>>,
firmware: Option<Vec<String>>,
+ imports_ns: Option<Vec<String>>,
+ params: Option<Vec<Parameter>>,
+}
+
+#[derive(Debug)]
+struct Parameter {
+ name: String,
+ ptype: String,
+ default: String,
+ description: String,
+}
+
+fn expect_params(it: &mut token_stream::IntoIter) -> Vec<Parameter> {
+ let params = expect_group(it);
+ assert_eq!(params.delimiter(), Delimiter::Brace);
+ let mut it = params.stream().into_iter();
+ let mut parsed = Vec::new();
+
+ loop {
+ let param_name = match it.next() {
+ Some(TokenTree::Ident(ident)) => ident.to_string(),
+ Some(_) => panic!("Expected Ident or end"),
+ None => break,
+ };
+
+ assert_eq!(expect_punct(&mut it), ':');
+ let param_type = expect_ident(&mut it);
+ let group = expect_group(&mut it);
+ assert_eq!(group.delimiter(), Delimiter::Brace);
+ assert_eq!(expect_punct(&mut it), ',');
+
+ let mut param_it = group.stream().into_iter();
+ let param_default = expect_param_default(&mut param_it);
+ let param_description = expect_string_field(&mut param_it, "description");
+ expect_end(&mut param_it);
+
+ parsed.push(Parameter {
+ name: param_name,
+ ptype: param_type,
+ default: param_default,
+ description: param_description,
+ })
+ }
+
+ parsed
}
impl ModuleInfo {
@@@ -263,7 -113,7 +264,8 @@@
"license",
"alias",
"firmware",
+ "imports_ns",
+ "params",
];
const REQUIRED_KEYS: &[&str] = &["type", "name", "license"];
let mut seen_keys = Vec::new();
@@@ -289,7 -139,7 +291,8 @@@
"license" => info.license = expect_string_ascii(it),
"alias" => info.alias = Some(expect_string_array(it)),
"firmware" => info.firmware = Some(expect_string_array(it)),
+ "imports_ns" => info.imports_ns = Some(expect_string_array(it)),
+ "params" => info.params = Some(expect_params(it)),
_ => panic!("Unknown key \"{key}\". Valid keys are: {EXPECTED_KEYS:?}."),
}
@@@ -329,25 -179,30 +332,30 @@@ pub(crate) fn module(ts: TokenStream) -
// Rust does not allow hyphens in identifiers, use underscore instead.
let ident = info.name.replace('-', "_");
let mut modinfo = ModInfoBuilder::new(ident.as_ref());
- if let Some(authors) = info.authors {
+ if let Some(authors) = &info.authors {
for author in authors {
- modinfo.emit("author", &author);
+ modinfo.emit("author", author);
}
}
- if let Some(description) = info.description {
- modinfo.emit("description", &description);
+ if let Some(description) = &info.description {
+ modinfo.emit("description", description);
}
modinfo.emit("license", &info.license);
- if let Some(aliases) = info.alias {
+ if let Some(aliases) = &info.alias {
for alias in aliases {
- modinfo.emit("alias", &alias);
+ modinfo.emit("alias", alias);
}
}
- if let Some(firmware) = info.firmware {
+ if let Some(firmware) = &info.firmware {
for fw in firmware {
- modinfo.emit("firmware", &fw);
+ modinfo.emit("firmware", fw);
}
}
- if let Some(imports) = info.imports_ns {
++ if let Some(imports) = &info.imports_ns {
+ for ns in imports {
+ modinfo.emit("import_ns", &ns);
+ }
+ }
// Built-in modules also export the `file` modinfo string.
let file =
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] docs: ABI: sysfs-module: update modules taint flags
From: Randy Dunlap @ 2025-11-02 6:04 UTC (permalink / raw)
To: linux-kernel
Cc: Randy Dunlap, Petr Pavlu, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Luis Chamberlain, Daniel Gomez, Sami Tolvanen,
linux-modules
Add missing taint flags for loadable modules, as pointed out by
Petr Pavlu [1].
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
[1] https://lore.kernel.org/all/c58152f1-0fbe-4f50-bb61-e2f4c0584025@suse.com/
---
Cc: Petr Pavlu <petr.pavlu@suse.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: Daniel Gomez <da.gomez@kernel.org>
Cc: Sami Tolvanen <samitolvanen@google.com>
Cc: linux-modules@vger.kernel.org
---
Documentation/ABI/testing/sysfs-module | 2 ++
1 file changed, 2 insertions(+)
--- linux-next-20251031.orig/Documentation/ABI/testing/sysfs-module
+++ linux-next-20251031/Documentation/ABI/testing/sysfs-module
@@ -59,6 +59,8 @@ Description: Module taint flags:
F force-loaded module
C staging driver module
E unsigned module
+ K livepatch module
+ N in-kernel test module
== =====================
What: /sys/module/grant_table/parameters/free_per_iteration
^ permalink raw reply
* Re: [PATCH] module: Only declare set_module_sig_enforced when CONFIG_MODULE_SIG=y
From: Daniel Gomez @ 2025-11-01 22:10 UTC (permalink / raw)
To: Coiby Xu, linux-modules
Cc: linux-integrity, kernel test robot, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, open list:MODULE SUPPORT
In-Reply-To: <20251031080949.2001716-1-coxu@redhat.com>
On 31/10/2025 09.09, Coiby Xu wrote:
> Currently, set_module_sig_enforced is declared as long as CONFIG_MODULES
> is enabled. This can lead to a linking error if
> set_module_sig_enforced is called with CONFIG_MODULE_SIG=n,
>
> ld: security/integrity/ima/ima_appraise.o: in function `ima_appraise_measurement':
> security/integrity/ima/ima_appraise.c:587:(.text+0xbbb): undefined reference to `set_module_sig_enforced'
It's a bit unclear whether you're referring to a current upstream issue (which I
couldn't find as of -rc3), or if this is just a hypothetical scenario.
>
> So only declare set_module_sig_enforced when CONFIG_MODULE_SIG is
> enabled.
I only see cases where code has a safeguard like in
security/integrity/ima/ima_efi.c:71
if (IS_ENABLED(CONFIG_MODULE_SIG))
set_module_sig_enforced();
>
> Note this issue hasn't caused a real problem because all current callers
> of set_module_sig_enforced e.g. security/integrity/ima/ima_efi.c
> depend on CONFIG_MODULE_SIG=y.
I think the correct term we should use here is runtime safeguard. The code does
not actually depend on that config, nor is there any dep in Kconfig.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202510030029.VRKgik99-lkp@intel.com/
> Signed-off-by: Coiby Xu <coxu@redhat.com>
Just minor nits regarding the commit message structure. This change should allow
us to remove the safeguard from users of set_module_sig_enforced().
Other than that, LGTM,
Reviewed-by: Daniel Gomez <da.gomez@samsung.com>
^ permalink raw reply
* Re: [PATCH v18 0/7] rust: extend `module!` macro with integer parameter support
From: Daniel Gomez @ 2025-11-01 21:39 UTC (permalink / raw)
To: Andreas Hindborg, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
Björn Roy Baron, Alice Ryhl, Masahiro Yamada,
Nathan Chancellor, Luis Chamberlain, Danilo Krummrich,
Benno Lossin, Nicolas Schier, Uwe Kleine-König,
Michal Wilczynski
Cc: Trevor Gross, Adam Bratschi-Kaye, rust-for-linux, linux-kernel,
linux-kbuild, Petr Pavlu, Sami Tolvanen, Daniel Gomez,
Simona Vetter, Greg KH, Fiona Behrens, Daniel Almeida,
linux-modules
In-Reply-To: <20250924-module-params-v3-v18-0-bf512c35d910@kernel.org>
On 24/09/2025 14.39, Andreas Hindborg wrote:
> Extend the `module!` macro with support module parameters. Also add some
> string to integer parsing functions.
>
> Based on the original module parameter support by Miguel [1],
> later extended and generalized by Adam for more types [2][3].
> Originally tracked at [4].
>
> Link: https://github.com/Rust-for-Linux/linux/pull/7 [1]
> Link: https://github.com/Rust-for-Linux/linux/pull/82 [2]
> Link: https://github.com/Rust-for-Linux/linux/pull/87 [3]
> Link: https://github.com/Rust-for-Linux/linux/issues/11 [4]
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
I tested this series with rust_minimal module. They LGTM,
Tested-by: Daniel Gomez <da.gomez@samsung.com>
The patches did not apply cleanly to v6.18-rc3, at least not when using b4.
However, when applying them to the base commit and then rebasing onto v6.18-rc3,
I didn't see any conflicts.
I've created a temporary branch with this rebase here:
https://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git/log/?h=rebase/20250924-module-params-v3-v18-0-bf512c35d910@kernel.org
Can you take a look when you can? I'll merge this shortly after checking with
Uwe, as there are some minor conflicts with his tree.
+ Uwe
These are the conflicts I see when merging the patch series from Michal [1]
(Introduce import_ns support for Rust). I believe these are trivial things that
we will get notified from linux-next merging. But let me know what you think as
you have requested in that thread.
[1] Link: https://lore.kernel.org/all/20251028-pwm_fixes-v1-0-25a532d31998@samsung.com/
...
Applying: rust: macros: Add support for 'imports_ns' to module!
Patch failed at 0008 rust: macros: Add support for 'imports_ns' to module!
error: patch failed: rust/macros/module.rs:98
error: rust/macros/module.rs: patch does not apply
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
git am --show-current-patch=diff
---
rust/macros/module.rs | 8 ++++++++
1 file changed, 8 insertions(+)
---
rust/macros/module.rs | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/rust/macros/module.rs b/rust/macros/module.rs
index 5ee54a00c0b65699596e660b2d4d60e64be2a50c..408cd115487514c8be79724d901c676435696376 100644
--- a/rust/macros/module.rs
+++ b/rust/macros/module.rs
@@ -98,6 +98,7 @@ struct ModuleInfo {
description: Option<String>,
alias: Option<Vec<String>>,
firmware: Option<Vec<String>>,
+ imports_ns: Option<Vec<String>>,
}
impl ModuleInfo {
@@ -112,6 +113,7 @@ fn parse(it: &mut token_stream::IntoIter) -> Self {
"license",
"alias",
"firmware",
+ "imports_ns",
];
const REQUIRED_KEYS: &[&str] = &["type", "name", "license"];
let mut seen_keys = Vec::new();
@@ -137,6 +139,7 @@ fn parse(it: &mut token_stream::IntoIter) -> Self {
"license" => info.license = expect_string_ascii(it),
"alias" => info.alias = Some(expect_string_array(it)),
"firmware" => info.firmware = Some(expect_string_array(it)),
+ "imports_ns" => info.imports_ns = Some(expect_string_array(it)),
_ => panic!("Unknown key \"{key}\". Valid keys are: {EXPECTED_KEYS:?}."),
}
@@ -195,6 +198,11 @@ pub(crate) fn module(ts: TokenStream) -> TokenStream {
modinfo.emit("firmware", &fw);
}
}
+ if let Some(imports) = info.imports_ns {
+ for ns in imports {
+ modinfo.emit("import_ns", &ns);
+ }
+ }
// Built-in modules also export the `file` modinfo string.
let file =
^ permalink raw reply related
* Re: [PATCH v2] lsm,ima: new LSM hook security_kernel_module_read_file to access decompressed kernel module
From: Paul Moore @ 2025-11-01 16:50 UTC (permalink / raw)
To: Coiby Xu
Cc: linux-integrity, linux-security-module, Mimi Zohar, 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: <20251031074016.1975356-1-coxu@redhat.com>
On Fri, Oct 31, 2025 at 3:41 AM Coiby Xu <coxu@redhat.com> wrote:
>
> Currently, when in-kernel module decompression (CONFIG_MODULE_DECOMPRESS)
> is enabled, IMA has no way to verify the appended module signature as it
> can't decompress the module.
>
> Define a new LSM hook security_kernel_module_read_file which will be
> called after kernel module decompression is done so IMA can access the
> decompressed kernel module to verify the appended signature.
>
> Since IMA can access both xattr and appended kernel module signature
> with the new LSM hook, it no longer uses the security_kernel_post_read_file
> LSM hook for kernel module loading.
>
> Before enabling in-kernel module decompression, a kernel module in
> initramfs can still be loaded with ima_policy=secure_boot. So adjust the
> kernel module rule in secure_boot policy to allow either an IMA
> signature OR an appended signature i.e. to use
> "appraise func=MODULE_CHECK appraise_type=imasig|modsig".
>
> Reported-by: Karel Srot <ksrot@redhat.com>
> Suggested-by: Mimi Zohar <zohar@linux.ibm.com>
> Signed-off-by: Coiby Xu <coxu@redhat.com>
> ---
> v1: https://lore.kernel.org/linux-integrity/20250928030358.3873311-1-coxu@redhat.com/
>
> include/linux/lsm_hook_defs.h | 2 ++
> include/linux/security.h | 7 +++++++
> kernel/module/main.c | 10 +++++++++-
> security/integrity/ima/ima_main.c | 26 ++++++++++++++++++++++++++
> security/integrity/ima/ima_policy.c | 2 +-
> security/security.c | 17 +++++++++++++++++
> 6 files changed, 62 insertions(+), 2 deletions(-)
We don't really need a new LSM hook for this do we? Can't we just
define a new file read type, e.g. READING_MODULE_DECOMPRESS, and do
another call to security_kernel_post_read_file() after the module is
unpacked? Something like the snippet below ...
diff --git a/kernel/module/main.c b/kernel/module/main.c
index c66b26184936..f127000d2e0a 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -3693,6 +3693,14 @@ static int init_module_from_file(struct file *f, const ch
ar __user * uargs, int
mod_stat_add_long(len, &invalid_decompress_bytes);
return err;
}
+
+ err = security_kernel_post_read_file(f,
+ (char *)info.hdr, info.len,
+ READING_MODULE_DECOMPRESS);
+ if (err) {
+ mod_stat_inc(&failed_kreads);
+ return err;
+ }
} else {
info.hdr = buf;
info.len = len;
--
paul-moore.com
^ permalink raw reply related
* Re: [PATCH 1/4] rust: macros: Add support for 'imports_ns' to module!
From: Uwe Kleine-König @ 2025-11-01 8:06 UTC (permalink / raw)
To: Daniel Gomez, Miguel Ojeda
Cc: Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Miguel Ojeda,
Alex Gaynor, Michal Wilczynski, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Drew Fustini, Guo Ren, Fu Wei,
Stephen Rothwell, rust-for-linux, linux-kernel, linux-pwm,
linux-riscv, linux-modules
In-Reply-To: <4654398f-324c-4465-88eb-8cadde6160dc@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1795 bytes --]
Hello Daniel, hello Miguel,
On Fri, Oct 31, 2025 at 02:12:29PM +0100, Daniel Gomez wrote:
> On 31/10/2025 13.57, Miguel Ojeda wrote:
> > On Fri, Oct 31, 2025 at 8:47 AM Uwe Kleine-König <ukleinek@kernel.org> wrote:
> > > Can I have some blessing to take this patch via my pwm tree? Would you
> > > prefer a tag to also merge it into your tree? Then I would apply it on
> > > top of 6.18-rc1 and provide a tag for you to merge.
> >
> > Sounds fine to me, but I am Cc'ing the modules maintainers since they
> > were not, just in case:
Good idea, thanks for catching that.
> > Acked-by: Miguel Ojeda <ojeda@kernel.org>
> > [...]
>
> Uwe, that's okay from modules side:
>
> Acked-by: Daniel Gomez <da.gomez@samsung.com>
Thanks for your Acks, I applied patches #1-#3 to
https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git pwm/for-next
(#4 was applied already).
> FYI, I haven't merged Andreas's patches (rust: extend `module!` macro with
> integer parameter support) yet, which add rust/macros/module.rs to our
> MAINTAINERS file list. So, it's fine from modules side to go through your tree.
> I was aiming to merge these patches along with some others for this week but
> I've found a regression in kmod testing introduced in the latest v6.18-rc1,
> which is taking me some extra time.
If the issues you mentioned are sorted out and you apply patches that
conflict with the changes I committed, please get in touch that we
coordinate if/how to sort them out.
Also if the need for a tag to share the commit arises, please coordinate
and don't just merge the just now created commits, as I like to be able
to rewrite my tree for late Acks etc. So I'd like to prepare and know
when commits become set in stone.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v8 04/23] slab: add sheaf support for batching kfree_rcu() operations
From: Daniel Gomez @ 2025-10-31 21:32 UTC (permalink / raw)
To: Vlastimil Babka, Suren Baghdasaryan, Liam R. Howlett,
Christoph Lameter, David Rientjes
Cc: Roman Gushchin, Harry Yoo, Uladzislau Rezki, Sidhartha Kumar,
linux-mm, linux-kernel, rcu, maple-tree, linux-modules,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Aaron Tomlin,
Lucas De Marchi
In-Reply-To: <20250910-slub-percpu-caches-v8-4-ca3099d8352c@suse.cz>
On 10/09/2025 10.01, Vlastimil Babka wrote:
> Extend the sheaf infrastructure for more efficient kfree_rcu() handling.
> For caches with sheaves, on each cpu maintain a rcu_free sheaf in
> addition to main and spare sheaves.
>
> kfree_rcu() operations will try to put objects on this sheaf. Once full,
> the sheaf is detached and submitted to call_rcu() with a handler that
> will try to put it in the barn, or flush to slab pages using bulk free,
> when the barn is full. Then a new empty sheaf must be obtained to put
> more objects there.
>
> It's possible that no free sheaves are available to use for a new
> rcu_free sheaf, and the allocation in kfree_rcu() context can only use
> GFP_NOWAIT and thus may fail. In that case, fall back to the existing
> kfree_rcu() implementation.
>
> Expected advantages:
> - batching the kfree_rcu() operations, that could eventually replace the
> existing batching
> - sheaves can be reused for allocations via barn instead of being
> flushed to slabs, which is more efficient
> - this includes cases where only some cpus are allowed to process rcu
> callbacks (Android)
>
> Possible disadvantage:
> - objects might be waiting for more than their grace period (it is
> determined by the last object freed into the sheaf), increasing memory
> usage - but the existing batching does that too.
>
> Only implement this for CONFIG_KVFREE_RCU_BATCHED as the tiny
> implementation favors smaller memory footprint over performance.
>
> Also for now skip the usage of rcu sheaf for CONFIG_PREEMPT_RT as the
> contexts where kfree_rcu() is called might not be compatible with taking
> a barn spinlock or a GFP_NOWAIT allocation of a new sheaf taking a
> spinlock - the current kfree_rcu() implementation avoids doing that.
>
> Teach kvfree_rcu_barrier() to flush all rcu_free sheaves from all caches
> that have them. This is not a cheap operation, but the barrier usage is
> rare - currently kmem_cache_destroy() or on module unload.
>
> Add CONFIG_SLUB_STATS counters free_rcu_sheaf and free_rcu_sheaf_fail to
> count how many kfree_rcu() used the rcu_free sheaf successfully and how
> many had to fall back to the existing implementation.
>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Hi Vlastimil,
This patch increases kmod selftest (stress module loader) runtime by about
~50-60%, from ~200s to ~300s total execution time. My tested kernel has
CONFIG_KVFREE_RCU_BATCHED enabled. Any idea or suggestions on what might be
causing this, or how to address it?
^ permalink raw reply
* Re: [PATCH] module: Only declare set_module_sig_enforced when CONFIG_MODULE_SIG=y
From: Aaron Tomlin @ 2025-10-31 20:09 UTC (permalink / raw)
To: Coiby Xu
Cc: linux-modules, linux-integrity, kernel test robot,
Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
open list:MODULE SUPPORT
In-Reply-To: <20251031080949.2001716-1-coxu@redhat.com>
On Fri, Oct 31, 2025 at 04:09:48PM +0800, Coiby Xu wrote:
> Currently, set_module_sig_enforced is declared as long as CONFIG_MODULES
> is enabled. This can lead to a linking error if
> set_module_sig_enforced is called with CONFIG_MODULE_SIG=n,
>
> ld: security/integrity/ima/ima_appraise.o: in function `ima_appraise_measurement':
> security/integrity/ima/ima_appraise.c:587:(.text+0xbbb): undefined reference to `set_module_sig_enforced'
>
> So only declare set_module_sig_enforced when CONFIG_MODULE_SIG is
> enabled.
>
> Note this issue hasn't caused a real problem because all current callers
> of set_module_sig_enforced e.g. security/integrity/ima/ima_efi.c
> depend on CONFIG_MODULE_SIG=y.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202510030029.VRKgik99-lkp@intel.com/
> Signed-off-by: Coiby Xu <coxu@redhat.com>
> ---
> include/linux/module.h | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/module.h b/include/linux/module.h
> index e135cc79acee..fa251958b138 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -769,8 +769,6 @@ static inline bool is_livepatch_module(struct module *mod)
> #endif
> }
>
> -void set_module_sig_enforced(void);
> -
> void module_for_each_mod(int(*func)(struct module *mod, void *data), void *data);
>
> #else /* !CONFIG_MODULES... */
> @@ -865,10 +863,6 @@ static inline bool module_requested_async_probing(struct module *module)
> }
>
>
> -static inline void set_module_sig_enforced(void)
> -{
> -}
> -
> /* Dereference module function descriptor */
> static inline
> void *dereference_module_function_descriptor(struct module *mod, void *ptr)
> @@ -924,6 +918,8 @@ static inline bool retpoline_module_ok(bool has_retpoline)
> #ifdef CONFIG_MODULE_SIG
> bool is_module_sig_enforced(void);
>
> +void set_module_sig_enforced(void);
> +
> static inline bool module_sig_ok(struct module *module)
> {
> return module->sig_ok;
> @@ -934,6 +930,10 @@ static inline bool is_module_sig_enforced(void)
> return false;
> }
>
> +static inline void set_module_sig_enforced(void)
> +{
> +}
> +
> static inline bool module_sig_ok(struct module *module)
> {
> return true;
>
> base-commit: e53642b87a4f4b03a8d7e5f8507fc3cd0c595ea6
> --
> 2.51.0
>
>
Looks good to me.
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
--
Aaron Tomlin
^ permalink raw reply
* Re: [PATCH 1/4] rust: macros: Add support for 'imports_ns' to module!
From: Daniel Gomez @ 2025-10-31 13:12 UTC (permalink / raw)
To: Miguel Ojeda, Uwe Kleine-König, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen
Cc: Miguel Ojeda, Alex Gaynor, Michal Wilczynski, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Danilo Krummrich, Drew Fustini, Guo Ren,
Fu Wei, Stephen Rothwell, rust-for-linux, linux-kernel, linux-pwm,
linux-riscv, linux-modules
In-Reply-To: <CANiq72nNxVJeMZdESrrB+LGmdRK+M5AGZbUw-x2aE-Qa-=HtJQ@mail.gmail.com>
On 31/10/2025 13.57, Miguel Ojeda wrote:
> On Fri, Oct 31, 2025 at 8:47 AM Uwe Kleine-König <ukleinek@kernel.org> wrote:
>>
>> I already asked this in reply to the cover letter, but the question was
>> lost on the way (no offense!), so I'm asking again. As it only really
>> affects this patch, I'm doing that here:
>>
>> Can I have some blessing to take this patch via my pwm tree? Would you
>> prefer a tag to also merge it into your tree? Then I would apply it on
>> top of 6.18-rc1 and provide a tag for you to merge.
>
> Sounds fine to me, but I am Cc'ing the modules maintainers since they
> were not, just in case:
>
> Acked-by: Miguel Ojeda <ojeda@kernel.org>
>
> I think we don't need the tag/merge, unless someone else is looking to
> use this (is there such a user? I may have missed it).
>
> Thanks!
>
> Cheers,
> Miguel
Uwe, that's okay from modules side:
Acked-by: Daniel Gomez <da.gomez@samsung.com>
FYI, I haven't merged Andreas's patches (rust: extend `module!` macro with
integer parameter support) yet, which add rust/macros/module.rs to our
MAINTAINERS file list. So, it's fine from modules side to go through your tree.
I was aiming to merge these patches along with some others for this week but
I've found a regression in kmod testing introduced in the latest v6.18-rc1,
which is taking me some extra time.
^ permalink raw reply
* Re: [PATCH 1/4] rust: macros: Add support for 'imports_ns' to module!
From: Miguel Ojeda @ 2025-10-31 12:57 UTC (permalink / raw)
To: Uwe Kleine-König, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen
Cc: Miguel Ojeda, Alex Gaynor, Michal Wilczynski, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Danilo Krummrich, Drew Fustini, Guo Ren,
Fu Wei, Stephen Rothwell, rust-for-linux, linux-kernel, linux-pwm,
linux-riscv, linux-modules
In-Reply-To: <h3sivr3uuzr5oodqe326svchbw3rzo4f4nw4chpeee2jwzjq3j@bdtecauehkn4>
On Fri, Oct 31, 2025 at 8:47 AM Uwe Kleine-König <ukleinek@kernel.org> wrote:
>
> I already asked this in reply to the cover letter, but the question was
> lost on the way (no offense!), so I'm asking again. As it only really
> affects this patch, I'm doing that here:
>
> Can I have some blessing to take this patch via my pwm tree? Would you
> prefer a tag to also merge it into your tree? Then I would apply it on
> top of 6.18-rc1 and provide a tag for you to merge.
Sounds fine to me, but I am Cc'ing the modules maintainers since they
were not, just in case:
Acked-by: Miguel Ojeda <ojeda@kernel.org>
I think we don't need the tag/merge, unless someone else is looking to
use this (is there such a user? I may have missed it).
Thanks!
Cheers,
Miguel
^ permalink raw reply
* [PATCH] module: Only declare set_module_sig_enforced when CONFIG_MODULE_SIG=y
From: Coiby Xu @ 2025-10-31 8:09 UTC (permalink / raw)
To: linux-modules
Cc: linux-integrity, kernel test robot, Luis Chamberlain, Petr Pavlu,
Daniel Gomez, Sami Tolvanen, open list:MODULE SUPPORT
Currently, set_module_sig_enforced is declared as long as CONFIG_MODULES
is enabled. This can lead to a linking error if
set_module_sig_enforced is called with CONFIG_MODULE_SIG=n,
ld: security/integrity/ima/ima_appraise.o: in function `ima_appraise_measurement':
security/integrity/ima/ima_appraise.c:587:(.text+0xbbb): undefined reference to `set_module_sig_enforced'
So only declare set_module_sig_enforced when CONFIG_MODULE_SIG is
enabled.
Note this issue hasn't caused a real problem because all current callers
of set_module_sig_enforced e.g. security/integrity/ima/ima_efi.c
depend on CONFIG_MODULE_SIG=y.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202510030029.VRKgik99-lkp@intel.com/
Signed-off-by: Coiby Xu <coxu@redhat.com>
---
include/linux/module.h | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index e135cc79acee..fa251958b138 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -769,8 +769,6 @@ static inline bool is_livepatch_module(struct module *mod)
#endif
}
-void set_module_sig_enforced(void);
-
void module_for_each_mod(int(*func)(struct module *mod, void *data), void *data);
#else /* !CONFIG_MODULES... */
@@ -865,10 +863,6 @@ static inline bool module_requested_async_probing(struct module *module)
}
-static inline void set_module_sig_enforced(void)
-{
-}
-
/* Dereference module function descriptor */
static inline
void *dereference_module_function_descriptor(struct module *mod, void *ptr)
@@ -924,6 +918,8 @@ static inline bool retpoline_module_ok(bool has_retpoline)
#ifdef CONFIG_MODULE_SIG
bool is_module_sig_enforced(void);
+void set_module_sig_enforced(void);
+
static inline bool module_sig_ok(struct module *module)
{
return module->sig_ok;
@@ -934,6 +930,10 @@ static inline bool is_module_sig_enforced(void)
return false;
}
+static inline void set_module_sig_enforced(void)
+{
+}
+
static inline bool module_sig_ok(struct module *module)
{
return true;
base-commit: e53642b87a4f4b03a8d7e5f8507fc3cd0c595ea6
--
2.51.0
^ permalink raw reply related
* [PATCH v2] lsm,ima: new LSM hook security_kernel_module_read_file to access decompressed kernel module
From: Coiby Xu @ 2025-10-31 7:40 UTC (permalink / raw)
To: linux-integrity, linux-security-module, Mimi Zohar
Cc: Karel Srot, Paul Moore, 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: <20250928030358.3873311-1-coxu@redhat.com>
Currently, when in-kernel module decompression (CONFIG_MODULE_DECOMPRESS)
is enabled, IMA has no way to verify the appended module signature as it
can't decompress the module.
Define a new LSM hook security_kernel_module_read_file which will be
called after kernel module decompression is done so IMA can access the
decompressed kernel module to verify the appended signature.
Since IMA can access both xattr and appended kernel module signature
with the new LSM hook, it no longer uses the security_kernel_post_read_file
LSM hook for kernel module loading.
Before enabling in-kernel module decompression, a kernel module in
initramfs can still be loaded with ima_policy=secure_boot. So adjust the
kernel module rule in secure_boot policy to allow either an IMA
signature OR an appended signature i.e. to use
"appraise func=MODULE_CHECK appraise_type=imasig|modsig".
Reported-by: Karel Srot <ksrot@redhat.com>
Suggested-by: Mimi Zohar <zohar@linux.ibm.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
---
v1: https://lore.kernel.org/linux-integrity/20250928030358.3873311-1-coxu@redhat.com/
include/linux/lsm_hook_defs.h | 2 ++
include/linux/security.h | 7 +++++++
kernel/module/main.c | 10 +++++++++-
security/integrity/ima/ima_main.c | 26 ++++++++++++++++++++++++++
security/integrity/ima/ima_policy.c | 2 +-
security/security.c | 17 +++++++++++++++++
6 files changed, 62 insertions(+), 2 deletions(-)
diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
index 8c42b4bde09c..ced42eb8b618 100644
--- a/include/linux/lsm_hook_defs.h
+++ b/include/linux/lsm_hook_defs.h
@@ -232,6 +232,8 @@ LSM_HOOK(int, 0, kernel_read_file, struct file *file,
enum kernel_read_file_id id, bool contents)
LSM_HOOK(int, 0, kernel_post_read_file, struct file *file, char *buf,
loff_t size, enum kernel_read_file_id id)
+LSM_HOOK(int, 0, kernel_module_read_file, struct file *file, char *buf,
+ loff_t size)
LSM_HOOK(int, 0, task_fix_setuid, struct cred *new, const struct cred *old,
int flags)
LSM_HOOK(int, 0, task_fix_setgid, struct cred *new, const struct cred * old,
diff --git a/include/linux/security.h b/include/linux/security.h
index 92ac3f27b973..e47951292c73 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -508,6 +508,7 @@ int security_kernel_read_file(struct file *file, enum kernel_read_file_id id,
bool contents);
int security_kernel_post_read_file(struct file *file, char *buf, loff_t size,
enum kernel_read_file_id id);
+int security_kernel_module_read_file(struct file *file, char *buf, loff_t size);
int security_task_fix_setuid(struct cred *new, const struct cred *old,
int flags);
int security_task_fix_setgid(struct cred *new, const struct cred *old,
@@ -1295,6 +1296,12 @@ static inline int security_kernel_post_read_file(struct file *file,
return 0;
}
+static inline int security_kernel_module_read_file(struct file *file,
+ char *buf, loff_t size)
+{
+ return 0;
+}
+
static inline int security_task_fix_setuid(struct cred *new,
const struct cred *old,
int flags)
diff --git a/kernel/module/main.c b/kernel/module/main.c
index c66b26184936..40bc86fa7384 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -3678,6 +3678,7 @@ static int init_module_from_file(struct file *f, const char __user * uargs, int
struct load_info info = { };
void *buf = NULL;
int len;
+ int err;
len = kernel_read_file(f, 0, &buf, INT_MAX, NULL, READING_MODULE);
if (len < 0) {
@@ -3686,7 +3687,7 @@ static int init_module_from_file(struct file *f, const char __user * uargs, int
}
if (flags & MODULE_INIT_COMPRESSED_FILE) {
- int err = module_decompress(&info, buf, len);
+ err = module_decompress(&info, buf, len);
vfree(buf); /* compressed data is no longer needed */
if (err) {
mod_stat_inc(&failed_decompress);
@@ -3698,6 +3699,13 @@ static int init_module_from_file(struct file *f, const char __user * uargs, int
info.len = len;
}
+ err = security_kernel_module_read_file(f, (char *)info.hdr, info.len);
+ if (err) {
+ mod_stat_inc(&failed_kreads);
+ free_copy(&info, flags);
+ return err;
+ }
+
return load_module(&info, uargs, flags);
}
diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
index cdd225f65a62..53d2e90176ea 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -635,6 +635,27 @@ static int ima_file_check(struct file *file, int mask)
MAY_APPEND), FILE_CHECK);
}
+/**
+ * ima_read_kernel_module - collect/appraise/audit measurement
+ * @file: file pointer to the module.
+ * @buf: buffer containing module data (possibly decompressed).
+ * @size: size of the buffer.
+ *
+ * This IMA hook for kernel_module_read_file LSM hook is called after a kernel
+ * module has been read into memory and (if applicable) decompressed. It
+ * measures and/or appraises the module based on the IMA policy.
+ *
+ * Return: 0 on success, negative error code on failure.
+ */
+static int ima_read_kernel_module(struct file *file, char *buf, loff_t size)
+{
+ struct lsm_prop prop;
+
+ security_current_getlsmprop_subj(&prop);
+ return process_measurement(file, current_cred(), &prop, buf, size,
+ MAY_READ, MODULE_CHECK);
+}
+
static int __ima_inode_hash(struct inode *inode, struct file *file, char *buf,
size_t buf_size)
{
@@ -881,6 +902,10 @@ static int ima_post_read_file(struct file *file, char *buf, loff_t size,
enum ima_hooks func;
struct lsm_prop prop;
+ /* kernel module will be addressed in ima_read_kernel_module */
+ if (read_id == READING_MODULE)
+ return 0;
+
/* permit signed certs */
if (!file && read_id == READING_X509_CERTIFICATE)
return 0;
@@ -1250,6 +1275,7 @@ static struct security_hook_list ima_hooks[] __ro_after_init = {
LSM_HOOK_INIT(kernel_load_data, ima_load_data),
LSM_HOOK_INIT(kernel_post_load_data, ima_post_load_data),
LSM_HOOK_INIT(kernel_read_file, ima_read_file),
+ LSM_HOOK_INIT(kernel_module_read_file, ima_read_kernel_module),
LSM_HOOK_INIT(kernel_post_read_file, ima_post_read_file),
LSM_HOOK_INIT(path_post_mknod, ima_post_path_mknod),
#ifdef CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS
diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
index 128fab897930..2c9bdc618ac9 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -241,7 +241,7 @@ static struct ima_rule_entry build_appraise_rules[] __ro_after_init = {
static struct ima_rule_entry secure_boot_rules[] __ro_after_init = {
{.action = APPRAISE, .func = MODULE_CHECK,
- .flags = IMA_FUNC | IMA_DIGSIG_REQUIRED},
+ .flags = IMA_FUNC | IMA_DIGSIG_REQUIRED | IMA_MODSIG_ALLOWED | IMA_CHECK_BLACKLIST},
{.action = APPRAISE, .func = FIRMWARE_CHECK,
.flags = IMA_FUNC | IMA_DIGSIG_REQUIRED},
{.action = APPRAISE, .func = KEXEC_KERNEL_CHECK,
diff --git a/security/security.c b/security/security.c
index 4d3c03a4524c..311ba63a8889 100644
--- a/security/security.c
+++ b/security/security.c
@@ -3442,6 +3442,23 @@ int security_kernel_post_read_file(struct file *file, char *buf, loff_t size,
}
EXPORT_SYMBOL_GPL(security_kernel_post_read_file);
+/**
+ * security_kernel_module_read_file() - Read a kernel module loaded by finit_module
+ * @file: file
+ * @buf: contents of decompressed kernel module
+ * @size: size of decompressed kernel module
+ *
+ * Read a kernel module loaded by the finit_module syscall. Unlike
+ * security_kernel_post_read_file, it has access to the decompressed kernel module.
+ *
+ * Return: Returns 0 if permission is granted.
+ */
+int security_kernel_module_read_file(struct file *file, char *buf, loff_t size)
+{
+ return call_int_hook(kernel_module_read_file, file, buf, size);
+}
+EXPORT_SYMBOL_GPL(security_kernel_module_read_file);
+
/**
* security_kernel_load_data() - Load data provided by userspace
* @id: data identifier
base-commit: e53642b87a4f4b03a8d7e5f8507fc3cd0c595ea6
--
2.51.0
^ permalink raw reply related
* Re: [syzbot] [mm?] BUG: soft lockup in sys_bpf
From: syzbot @ 2025-10-25 15:30 UTC (permalink / raw)
To: akpm, apopple, byungchul, da.gomez, david, gourry, joshua.hahnjy,
linux-kernel, linux-mm, linux-modules, matthew.brost, mcgrof,
netdev, petr.pavlu, rakie.kim, samitolvanen, syzkaller-bugs,
ying.huang, ziy
In-Reply-To: <68087f2f.050a0220.dd94f.0177.GAE@google.com>
syzbot has found a reproducer for the following issue on:
HEAD commit: 566771afc7a8 Merge tag 'v6.18-rc2-smb-server-fixes' of git..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15c8ee7c580000
kernel config: https://syzkaller.appspot.com/x/.config?x=8345ce4ce316ca28
dashboard link: https://syzkaller.appspot.com/bug?extid=9431dc0c0741cff46a99
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=157013cd980000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=130cc7e2580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/52417ef1f782/disk-566771af.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/66730a263bf1/vmlinux-566771af.xz
kernel image: https://storage.googleapis.com/syzbot-assets/1fe0762efb1f/bzImage-566771af.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+9431dc0c0741cff46a99@syzkaller.appspotmail.com
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): P5823
rcu: (detected by 1, t=10502 jiffies, g=8989, q=37467 ncpus=2)
task:syz-executor333 state:R running task stack:24744 pid:5823 tgid:5823 ppid:5816 task_flags:0x400140 flags:0x00080001
Call Trace:
<IRQ>
sched_show_task+0x49d/0x630 kernel/sched/core.c:7901
rcu_print_detail_task_stall_rnp kernel/rcu/tree_stall.h:292 [inline]
print_other_cpu_stall+0xf78/0x1340 kernel/rcu/tree_stall.h:681
check_cpu_stall kernel/rcu/tree_stall.h:857 [inline]
rcu_pending kernel/rcu/tree.c:3671 [inline]
rcu_sched_clock_irq+0xa47/0x11b0 kernel/rcu/tree.c:2706
update_process_times+0x235/0x2d0 kernel/time/timer.c:2473
tick_sched_handle kernel/time/tick-sched.c:276 [inline]
tick_nohz_handler+0x39a/0x520 kernel/time/tick-sched.c:297
__run_hrtimer kernel/time/hrtimer.c:1777 [inline]
__hrtimer_run_queues+0x506/0xd40 kernel/time/hrtimer.c:1841
hrtimer_interrupt+0x45d/0xa90 kernel/time/hrtimer.c:1903
local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1041 [inline]
__sysvec_apic_timer_interrupt+0x10b/0x410 arch/x86/kernel/apic/apic.c:1058
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline]
sysvec_apic_timer_interrupt+0xa1/0xc0 arch/x86/kernel/apic/apic.c:1052
</IRQ>
<TASK>
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
RIP: 0010:instrument_atomic_read include/linux/instrumented.h:68 [inline]
RIP: 0010:_test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]
RIP: 0010:get_page_from_freelist+0x459/0x2960 mm/page_alloc.c:3824
Code: 8c 0d 00 48 8b 74 24 18 49 b8 00 00 00 00 00 fc ff df 48 8b 03 48 39 d8 0f 84 7e 07 00 00 48 8b 44 24 08 4c 8d a0 38 06 00 00 <4c> 89 e7 be 08 00 00 00 e8 ba 8e 0d 00 48 b9 00 00 00 00 00 fc ff
RSP: 0018:ffffc90004c97158 EFLAGS: 00000206
RAX: ffff88823fff8740 RBX: ffff88823fffc888 RCX: dffffc0000000000
RDX: 0000000000000001 RSI: ffff88813fffdf70 RDI: ffff88813fffdf70
RBP: 0000000000000000 R08: dffffc0000000000 R09: 1ffff11027fff7da
R10: dffffc0000000000 R11: ffffed1027fff7db R12: ffff88823fff8d78
R13: 0000000000000830 R14: ffffc90004c97448 R15: ffffc90004c9745c
__alloc_pages_slowpath+0x33b/0xe50 mm/page_alloc.c:4714
__alloc_frozen_pages_noprof+0x319/0x370 mm/page_alloc.c:5196
alloc_pages_mpol+0xd1/0x380 mm/mempolicy.c:2416
alloc_slab_page mm/slub.c:3055 [inline]
allocate_slab+0x96/0x350 mm/slub.c:3228
new_slab mm/slub.c:3282 [inline]
___slab_alloc+0xb12/0x13f0 mm/slub.c:4651
__slab_alloc+0xc6/0x1f0 mm/slub.c:4770
__slab_alloc_node mm/slub.c:4846 [inline]
slab_alloc_node mm/slub.c:5268 [inline]
kmem_cache_alloc_noprof+0xec/0x6b0 mm/slub.c:5287
skb_clone+0x212/0x3a0 net/core/skbuff.c:2050
____bpf_clone_redirect net/core/filter.c:2465 [inline]
bpf_clone_redirect+0xad/0x3d0 net/core/filter.c:2450
bpf_prog_3e1cbbed0c4acd81+0x5f/0x68
bpf_dispatcher_nop_func include/linux/bpf.h:1350 [inline]
__bpf_prog_run include/linux/filter.h:721 [inline]
bpf_prog_run include/linux/filter.h:728 [inline]
bpf_test_run+0x313/0x7a0 net/bpf/test_run.c:423
bpf_prog_test_run_skb+0xb4e/0x1550 net/bpf/test_run.c:1091
bpf_prog_test_run+0x2cd/0x340 kernel/bpf/syscall.c:4688
__sys_bpf+0x562/0x860 kernel/bpf/syscall.c:6167
__do_sys_bpf kernel/bpf/syscall.c:6259 [inline]
__se_sys_bpf kernel/bpf/syscall.c:6257 [inline]
__x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6257
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f0d40505cb9
Code: Unable to access opcode bytes at 0x7f0d40505c8f.
RSP: 002b:00007fff9d9b3ed8 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0d40505cb9
RDX: 0000000000000050 RSI: 00002000000000c0 RDI: 000000000000000a
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000006
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001
</TASK>
---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
^ permalink raw reply
* Re: [PATCH v2 10/10] module loader: enforce symbol import protection
From: kernel test robot @ 2025-10-23 9:58 UTC (permalink / raw)
To: Siddharth Nayyar, petr.pavlu
Cc: llvm, oe-kbuild-all, arnd, linux-arch, linux-kbuild, linux-kernel,
linux-modules, mcgrof, nathan, nicolas.schier, samitolvanen,
sidnayyar, maennich, gprocida
In-Reply-To: <20251013153918.2206045-11-sidnayyar@google.com>
Hi Siddharth,
kernel test robot noticed the following build errors:
[auto build test ERROR on arnd-asm-generic/master]
[also build test ERROR on soc/for-next linus/master v6.18-rc2 next-20251023]
[cannot apply to mcgrof/modules-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Siddharth-Nayyar/define-kernel-symbol-flags/20251021-104658
base: https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git master
patch link: https://lore.kernel.org/r/20251013153918.2206045-11-sidnayyar%40google.com
patch subject: [PATCH v2 10/10] module loader: enforce symbol import protection
config: x86_64-kexec (https://download.01.org/0day-ci/archive/20251023/202510231707.zbQhQZmN-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251023/202510231707.zbQhQZmN-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202510231707.zbQhQZmN-lkp@intel.com/
All errors (new ones prefixed by >>):
>> kernel/module/main.c:1271:32: error: no member named 'sig_ok' in 'struct module'
1271 | if (fsa.is_protected && !mod->sig_ok) {
| ~~~ ^
1 error generated.
vim +1271 kernel/module/main.c
1228
1229 /* Resolve a symbol for this module. I.e. if we find one, record usage. */
1230 static const struct kernel_symbol *resolve_symbol(struct module *mod,
1231 const struct load_info *info,
1232 const char *name,
1233 char ownername[])
1234 {
1235 struct find_symbol_arg fsa = {
1236 .name = name,
1237 .gplok = !(mod->taints & (1 << TAINT_PROPRIETARY_MODULE)),
1238 .warn = true,
1239 };
1240 int err;
1241
1242 /*
1243 * The module_mutex should not be a heavily contended lock;
1244 * if we get the occasional sleep here, we'll go an extra iteration
1245 * in the wait_event_interruptible(), which is harmless.
1246 */
1247 sched_annotate_sleep();
1248 mutex_lock(&module_mutex);
1249 if (!find_symbol(&fsa))
1250 goto unlock;
1251
1252 if (fsa.license == GPL_ONLY)
1253 mod->using_gplonly_symbols = true;
1254
1255 if (!inherit_taint(mod, fsa.owner, name)) {
1256 fsa.sym = NULL;
1257 goto getname;
1258 }
1259
1260 if (!check_version(info, name, mod, fsa.crc)) {
1261 fsa.sym = ERR_PTR(-EINVAL);
1262 goto getname;
1263 }
1264
1265 err = verify_namespace_is_imported(info, fsa.sym, mod);
1266 if (err) {
1267 fsa.sym = ERR_PTR(err);
1268 goto getname;
1269 }
1270
> 1271 if (fsa.is_protected && !mod->sig_ok) {
1272 pr_warn("%s: Cannot use protected symbol %s\n",
1273 mod->name, name);
1274 fsa.sym = ERR_PTR(-EACCES);
1275 goto getname;
1276 }
1277
1278 err = ref_module(mod, fsa.owner);
1279 if (err) {
1280 fsa.sym = ERR_PTR(err);
1281 goto getname;
1282 }
1283
1284 getname:
1285 /* We must make copy under the lock if we failed to get ref. */
1286 strscpy(ownername, module_name(fsa.owner), MODULE_NAME_LEN);
1287 unlock:
1288 mutex_unlock(&module_mutex);
1289 return fsa.sym;
1290 }
1291
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] params: Replace __modinit with __init_or_module
From: Aaron Tomlin @ 2025-10-23 2:45 UTC (permalink / raw)
To: Petr Pavlu
Cc: Luis Chamberlain, Daniel Gomez, Sami Tolvanen, Shyam Saini,
Rasmus Villemoes, linux-modules, linux-kernel
In-Reply-To: <20250819121248.460105-1-petr.pavlu@suse.com>
On Tue, Aug 19, 2025 at 02:12:09PM +0200, Petr Pavlu wrote:
> Remove the custom __modinit macro from kernel/params.c and instead use the
> common __init_or_module macro from include/linux/module.h. Both provide the
> same functionality.
>
> Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
> ---
> kernel/params.c | 15 +++++----------
> 1 file changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/kernel/params.c b/kernel/params.c
> index b92d64161b75..19bb04f10372 100644
> --- a/kernel/params.c
> +++ b/kernel/params.c
> @@ -595,12 +595,6 @@ static ssize_t param_attr_store(const struct module_attribute *mattr,
> }
> #endif
>
> -#ifdef CONFIG_MODULES
> -#define __modinit
> -#else
> -#define __modinit __init
> -#endif
> -
> #ifdef CONFIG_SYSFS
> void kernel_param_lock(struct module *mod)
> {
> @@ -625,9 +619,9 @@ EXPORT_SYMBOL(kernel_param_unlock);
> * create file in sysfs. Returns an error on out of memory. Always cleans up
> * if there's an error.
> */
> -static __modinit int add_sysfs_param(struct module_kobject *mk,
> - const struct kernel_param *kp,
> - const char *name)
> +static __init_or_module int add_sysfs_param(struct module_kobject *mk,
> + const struct kernel_param *kp,
> + const char *name)
> {
> struct module_param_attrs *new_mp;
> struct attribute **new_attrs;
> @@ -760,7 +754,8 @@ void destroy_params(const struct kernel_param *params, unsigned num)
> params[i].ops->free(params[i].arg);
> }
>
> -struct module_kobject __modinit * lookup_or_create_module_kobject(const char *name)
> +struct module_kobject * __init_or_module
> +lookup_or_create_module_kobject(const char *name)
> {
> struct module_kobject *mk;
> struct kobject *kobj;
>
> base-commit: be48bcf004f9d0c9207ff21d0edb3b42f253829e
> --
> 2.50.1
>
>
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
--
Aaron Tomlin
^ permalink raw reply
* Re: [PATCH] module: Remove unused __INIT*_OR_MODULE macros
From: Aaron Tomlin @ 2025-10-23 2:43 UTC (permalink / raw)
To: Petr Pavlu
Cc: Luis Chamberlain, Daniel Gomez, Sami Tolvanen, linux-modules,
linux-kernel
In-Reply-To: <20250819121423.460156-1-petr.pavlu@suse.com>
On Tue, Aug 19, 2025 at 02:13:37PM +0200, Petr Pavlu wrote:
> Remove the __INIT_OR_MODULE, __INITDATA_OR_MODULE and
> __INITRODATA_OR_MODULE macros. These were introduced in commit 8b5a10fc6fd0
> ("x86: properly annotate alternatives.c"). Only __INITRODATA_OR_MODULE was
> ever used, in arch/x86/kernel/alternative.c. In 2011, commit dc326fca2b64
> ("x86, cpu: Clean up and unify the NOP selection infrastructure") removed
> this usage.
>
> Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
> ---
> include/linux/module.h | 6 ------
> 1 file changed, 6 deletions(-)
>
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 3319a5269d28..e9e6eeb042aa 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -151,16 +151,10 @@ extern void cleanup_module(void);
> #define __init_or_module
> #define __initdata_or_module
> #define __initconst_or_module
> -#define __INIT_OR_MODULE .text
> -#define __INITDATA_OR_MODULE .data
> -#define __INITRODATA_OR_MODULE .section ".rodata","a",%progbits
> #else
> #define __init_or_module __init
> #define __initdata_or_module __initdata
> #define __initconst_or_module __initconst
> -#define __INIT_OR_MODULE __INIT
> -#define __INITDATA_OR_MODULE __INITDATA
> -#define __INITRODATA_OR_MODULE __INITRODATA
> #endif /*CONFIG_MODULES*/
>
> struct module_kobject *lookup_or_create_module_kobject(const char *name);
>
> base-commit: be48bcf004f9d0c9207ff21d0edb3b42f253829e
> --
> 2.50.1
>
>
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
--
Aaron Tomlin
^ permalink raw reply
* Re: [PATCH v2 10/10] module loader: enforce symbol import protection
From: kernel test robot @ 2025-10-23 2:36 UTC (permalink / raw)
To: Siddharth Nayyar, petr.pavlu
Cc: oe-kbuild-all, arnd, linux-arch, linux-kbuild, linux-kernel,
linux-modules, mcgrof, nathan, nicolas.schier, samitolvanen,
sidnayyar, maennich, gprocida
In-Reply-To: <20251013153918.2206045-11-sidnayyar@google.com>
Hi Siddharth,
kernel test robot noticed the following build errors:
[auto build test ERROR on arnd-asm-generic/master]
[also build test ERROR on soc/for-next linus/master v6.18-rc2 next-20251022]
[cannot apply to mcgrof/modules-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Siddharth-Nayyar/define-kernel-symbol-flags/20251021-104658
base: https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git master
patch link: https://lore.kernel.org/r/20251013153918.2206045-11-sidnayyar%40google.com
patch subject: [PATCH v2 10/10] module loader: enforce symbol import protection
config: x86_64-randconfig-122-20251022 (https://download.01.org/0day-ci/archive/20251023/202510231021.yaURwkIz-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251023/202510231021.yaURwkIz-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202510231021.yaURwkIz-lkp@intel.com/
All errors (new ones prefixed by >>):
kernel/module/main.c: In function 'resolve_symbol':
>> kernel/module/main.c:1271:37: error: 'struct module' has no member named 'sig_ok'
1271 | if (fsa.is_protected && !mod->sig_ok) {
| ^~
vim +1271 kernel/module/main.c
1228
1229 /* Resolve a symbol for this module. I.e. if we find one, record usage. */
1230 static const struct kernel_symbol *resolve_symbol(struct module *mod,
1231 const struct load_info *info,
1232 const char *name,
1233 char ownername[])
1234 {
1235 struct find_symbol_arg fsa = {
1236 .name = name,
1237 .gplok = !(mod->taints & (1 << TAINT_PROPRIETARY_MODULE)),
1238 .warn = true,
1239 };
1240 int err;
1241
1242 /*
1243 * The module_mutex should not be a heavily contended lock;
1244 * if we get the occasional sleep here, we'll go an extra iteration
1245 * in the wait_event_interruptible(), which is harmless.
1246 */
1247 sched_annotate_sleep();
1248 mutex_lock(&module_mutex);
1249 if (!find_symbol(&fsa))
1250 goto unlock;
1251
1252 if (fsa.license == GPL_ONLY)
1253 mod->using_gplonly_symbols = true;
1254
1255 if (!inherit_taint(mod, fsa.owner, name)) {
1256 fsa.sym = NULL;
1257 goto getname;
1258 }
1259
1260 if (!check_version(info, name, mod, fsa.crc)) {
1261 fsa.sym = ERR_PTR(-EINVAL);
1262 goto getname;
1263 }
1264
1265 err = verify_namespace_is_imported(info, fsa.sym, mod);
1266 if (err) {
1267 fsa.sym = ERR_PTR(err);
1268 goto getname;
1269 }
1270
> 1271 if (fsa.is_protected && !mod->sig_ok) {
1272 pr_warn("%s: Cannot use protected symbol %s\n",
1273 mod->name, name);
1274 fsa.sym = ERR_PTR(-EACCES);
1275 goto getname;
1276 }
1277
1278 err = ref_module(mod, fsa.owner);
1279 if (err) {
1280 fsa.sym = ERR_PTR(err);
1281 goto getname;
1282 }
1283
1284 getname:
1285 /* We must make copy under the lock if we failed to get ref. */
1286 strscpy(ownername, module_name(fsa.owner), MODULE_NAME_LEN);
1287 unlock:
1288 mutex_unlock(&module_mutex);
1289 return fsa.sym;
1290 }
1291
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] module: Remove unused __INIT*_OR_MODULE macros
From: Daniel Gomez @ 2025-10-22 22:55 UTC (permalink / raw)
To: Petr Pavlu, Luis Chamberlain, Sami Tolvanen; +Cc: linux-modules, linux-kernel
In-Reply-To: <20250819121423.460156-1-petr.pavlu@suse.com>
On 19/08/2025 14.13, Petr Pavlu wrote:
> Remove the __INIT_OR_MODULE, __INITDATA_OR_MODULE and
> __INITRODATA_OR_MODULE macros. These were introduced in commit 8b5a10fc6fd0
> ("x86: properly annotate alternatives.c"). Only __INITRODATA_OR_MODULE was
> ever used, in arch/x86/kernel/alternative.c. In 2011, commit dc326fca2b64
> ("x86, cpu: Clean up and unify the NOP selection infrastructure") removed
> this usage.
>
> Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
Reviewed-by: Daniel Gomez <da.gomez@samsung.com>
> ---
> include/linux/module.h | 6 ------
> 1 file changed, 6 deletions(-)
>
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 3319a5269d28..e9e6eeb042aa 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -151,16 +151,10 @@ extern void cleanup_module(void);
> #define __init_or_module
> #define __initdata_or_module
> #define __initconst_or_module
> -#define __INIT_OR_MODULE .text
> -#define __INITDATA_OR_MODULE .data
> -#define __INITRODATA_OR_MODULE .section ".rodata","a",%progbits
> #else
> #define __init_or_module __init
> #define __initdata_or_module __initdata
> #define __initconst_or_module __initconst
> -#define __INIT_OR_MODULE __INIT
> -#define __INITDATA_OR_MODULE __INITDATA
> -#define __INITRODATA_OR_MODULE __INITRODATA
> #endif /*CONFIG_MODULES*/
>
> struct module_kobject *lookup_or_create_module_kobject(const char *name);
>
> base-commit: be48bcf004f9d0c9207ff21d0edb3b42f253829e
^ permalink raw reply
* Re: [PATCH] params: Replace __modinit with __init_or_module
From: Daniel Gomez @ 2025-10-22 22:55 UTC (permalink / raw)
To: Petr Pavlu, Luis Chamberlain, Sami Tolvanen
Cc: Shyam Saini, Rasmus Villemoes, linux-modules, linux-kernel
In-Reply-To: <20250819121248.460105-1-petr.pavlu@suse.com>
On 19/08/2025 14.12, Petr Pavlu wrote:
> Remove the custom __modinit macro from kernel/params.c and instead use the
> common __init_or_module macro from include/linux/module.h. Both provide the
> same functionality.
>
> Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
Reviewed-by: Daniel Gomez <da.gomez@samsung.com>
> ---
> kernel/params.c | 15 +++++----------
> 1 file changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/kernel/params.c b/kernel/params.c
> index b92d64161b75..19bb04f10372 100644
> --- a/kernel/params.c
> +++ b/kernel/params.c
> @@ -595,12 +595,6 @@ static ssize_t param_attr_store(const struct module_attribute *mattr,
> }
> #endif
>
> -#ifdef CONFIG_MODULES
> -#define __modinit
> -#else
> -#define __modinit __init
> -#endif
> -
> #ifdef CONFIG_SYSFS
> void kernel_param_lock(struct module *mod)
> {
> @@ -625,9 +619,9 @@ EXPORT_SYMBOL(kernel_param_unlock);
> * create file in sysfs. Returns an error on out of memory. Always cleans up
> * if there's an error.
> */
> -static __modinit int add_sysfs_param(struct module_kobject *mk,
> - const struct kernel_param *kp,
> - const char *name)
> +static __init_or_module int add_sysfs_param(struct module_kobject *mk,
> + const struct kernel_param *kp,
> + const char *name)
> {
> struct module_param_attrs *new_mp;
> struct attribute **new_attrs;
> @@ -760,7 +754,8 @@ void destroy_params(const struct kernel_param *params, unsigned num)
> params[i].ops->free(params[i].arg);
> }
>
> -struct module_kobject __modinit * lookup_or_create_module_kobject(const char *name)
> +struct module_kobject * __init_or_module
> +lookup_or_create_module_kobject(const char *name)
> {
> struct module_kobject *mk;
> struct kobject *kobj;
>
> base-commit: be48bcf004f9d0c9207ff21d0edb3b42f253829e
^ permalink raw reply
* Re: [PATCH] taint/module: Remove unnecessary taint_flag.module field
From: Randy Dunlap @ 2025-10-22 19:31 UTC (permalink / raw)
To: Petr Pavlu, Andrew Morton
Cc: Luis Chamberlain, Daniel Gomez, Sami Tolvanen, Aaron Tomlin,
Petr Mladek, linux-modules, linux-kernel
In-Reply-To: <20251022082938.26670-1-petr.pavlu@suse.com>
On 10/22/25 1:28 AM, Petr Pavlu wrote:
> The TAINT_RANDSTRUCT and TAINT_FWCTL flags are mistakenly set in the
> taint_flags table as per-module flags. While this can be trivially
Ah, I had just noticed these this morning.
> corrected, the issue can be avoided altogether by removing the
> taint_flag.module field.
>
> This is possible because, since commit 7fd8329ba502 ("taint/module: Clean
> up global and module taint flags handling") in 2016, the handling of module
> taint flags has been fully generic. Specifically, module_flags_taint() can
> print all flags, and the required output buffer size is properly defined in
> terms of TAINT_FLAGS_COUNT. The actual per-module flags are always those
> added to module.taints by calls to add_taint_module().
>
> Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> The patch is based on linux-next (20251021) because I wanted to avoid
> a conflict with "taint: add reminder about updating docs and scripts" [1],
> which is currently queued in mm-nonmm-unstable.
>
> [1] https://lore.kernel.org/all/20251015221626.1126156-1-rdunlap@infradead.org/
>
> ---
> include/linux/panic.h | 1 -
> kernel/module/main.c | 2 +-
> kernel/panic.c | 46 ++++++++++++++++++++-----------------------
> 3 files changed, 22 insertions(+), 27 deletions(-)
>
--
~Randy
^ permalink raw reply
* Re: [PATCH] taint/module: Remove unnecessary taint_flag.module field
From: Petr Mladek @ 2025-10-22 10:19 UTC (permalink / raw)
To: Petr Pavlu
Cc: Andrew Morton, Luis Chamberlain, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Randy Dunlap, linux-modules, linux-kernel
In-Reply-To: <20251022082938.26670-1-petr.pavlu@suse.com>
On Wed 2025-10-22 10:28:04, Petr Pavlu wrote:
> The TAINT_RANDSTRUCT and TAINT_FWCTL flags are mistakenly set in the
> taint_flags table as per-module flags. While this can be trivially
> corrected, the issue can be avoided altogether by removing the
> taint_flag.module field.
>
> This is possible because, since commit 7fd8329ba502 ("taint/module: Clean
> up global and module taint flags handling") in 2016, the handling of module
> taint flags has been fully generic. Specifically, module_flags_taint() can
> print all flags, and the required output buffer size is properly defined in
> terms of TAINT_FLAGS_COUNT. The actual per-module flags are always those
> added to module.taints by calls to add_taint_module().
>
> Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
Makes sense. Nice trick!
Acked-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
^ permalink raw reply
* [PATCH] taint/module: Remove unnecessary taint_flag.module field
From: Petr Pavlu @ 2025-10-22 8:28 UTC (permalink / raw)
To: Andrew Morton
Cc: Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Randy Dunlap, Petr Mladek, linux-modules,
linux-kernel
The TAINT_RANDSTRUCT and TAINT_FWCTL flags are mistakenly set in the
taint_flags table as per-module flags. While this can be trivially
corrected, the issue can be avoided altogether by removing the
taint_flag.module field.
This is possible because, since commit 7fd8329ba502 ("taint/module: Clean
up global and module taint flags handling") in 2016, the handling of module
taint flags has been fully generic. Specifically, module_flags_taint() can
print all flags, and the required output buffer size is properly defined in
terms of TAINT_FLAGS_COUNT. The actual per-module flags are always those
added to module.taints by calls to add_taint_module().
Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
---
The patch is based on linux-next (20251021) because I wanted to avoid
a conflict with "taint: add reminder about updating docs and scripts" [1],
which is currently queued in mm-nonmm-unstable.
[1] https://lore.kernel.org/all/20251015221626.1126156-1-rdunlap@infradead.org/
---
include/linux/panic.h | 1 -
kernel/module/main.c | 2 +-
kernel/panic.c | 46 ++++++++++++++++++++-----------------------
3 files changed, 22 insertions(+), 27 deletions(-)
diff --git a/include/linux/panic.h b/include/linux/panic.h
index 6f972a66c13e..a00bc0937698 100644
--- a/include/linux/panic.h
+++ b/include/linux/panic.h
@@ -86,7 +86,6 @@ static inline void set_arch_panic_timeout(int timeout, int arch_default_timeout)
struct taint_flag {
char c_true; /* character printed when tainted */
char c_false; /* character printed when not tainted */
- bool module; /* also show as a per-module taint flag */
const char *desc; /* verbose description of the set taint flag */
};
diff --git a/kernel/module/main.c b/kernel/module/main.c
index c66b26184936..6f219751df7e 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -954,7 +954,7 @@ size_t module_flags_taint(unsigned long taints, char *buf)
int i;
for (i = 0; i < TAINT_FLAGS_COUNT; i++) {
- if (taint_flags[i].module && test_bit(i, &taints))
+ if (test_bit(i, &taints))
buf[l++] = taint_flags[i].c_true;
}
diff --git a/kernel/panic.c b/kernel/panic.c
index 81b7911fb5ca..341c66948dcb 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -628,17 +628,13 @@ void panic(const char *fmt, ...)
}
EXPORT_SYMBOL(panic);
-#define TAINT_FLAG(taint, _c_true, _c_false, _module) \
+#define TAINT_FLAG(taint, _c_true, _c_false) \
[ TAINT_##taint ] = { \
.c_true = _c_true, .c_false = _c_false, \
- .module = _module, \
.desc = #taint, \
}
/*
- * TAINT_FORCED_RMMOD could be a per-module flag but the module
- * is being removed anyway.
- *
* NOTE: if you modify the taint_flags or TAINT_FLAGS_COUNT,
* please also modify tools/debugging/kernel-chktaint and
* Documentation/admin-guide/tainted-kernels.rst, including its
@@ -646,26 +642,26 @@ EXPORT_SYMBOL(panic);
* /proc/sys/kernel/tainted.
*/
const struct taint_flag taint_flags[TAINT_FLAGS_COUNT] = {
- TAINT_FLAG(PROPRIETARY_MODULE, 'P', 'G', true),
- TAINT_FLAG(FORCED_MODULE, 'F', ' ', true),
- TAINT_FLAG(CPU_OUT_OF_SPEC, 'S', ' ', false),
- TAINT_FLAG(FORCED_RMMOD, 'R', ' ', false),
- TAINT_FLAG(MACHINE_CHECK, 'M', ' ', false),
- TAINT_FLAG(BAD_PAGE, 'B', ' ', false),
- TAINT_FLAG(USER, 'U', ' ', false),
- TAINT_FLAG(DIE, 'D', ' ', false),
- TAINT_FLAG(OVERRIDDEN_ACPI_TABLE, 'A', ' ', false),
- TAINT_FLAG(WARN, 'W', ' ', false),
- TAINT_FLAG(CRAP, 'C', ' ', true),
- TAINT_FLAG(FIRMWARE_WORKAROUND, 'I', ' ', false),
- TAINT_FLAG(OOT_MODULE, 'O', ' ', true),
- TAINT_FLAG(UNSIGNED_MODULE, 'E', ' ', true),
- TAINT_FLAG(SOFTLOCKUP, 'L', ' ', false),
- TAINT_FLAG(LIVEPATCH, 'K', ' ', true),
- TAINT_FLAG(AUX, 'X', ' ', true),
- TAINT_FLAG(RANDSTRUCT, 'T', ' ', true),
- TAINT_FLAG(TEST, 'N', ' ', true),
- TAINT_FLAG(FWCTL, 'J', ' ', true),
+ TAINT_FLAG(PROPRIETARY_MODULE, 'P', 'G'),
+ TAINT_FLAG(FORCED_MODULE, 'F', ' '),
+ TAINT_FLAG(CPU_OUT_OF_SPEC, 'S', ' '),
+ TAINT_FLAG(FORCED_RMMOD, 'R', ' '),
+ TAINT_FLAG(MACHINE_CHECK, 'M', ' '),
+ TAINT_FLAG(BAD_PAGE, 'B', ' '),
+ TAINT_FLAG(USER, 'U', ' '),
+ TAINT_FLAG(DIE, 'D', ' '),
+ TAINT_FLAG(OVERRIDDEN_ACPI_TABLE, 'A', ' '),
+ TAINT_FLAG(WARN, 'W', ' '),
+ TAINT_FLAG(CRAP, 'C', ' '),
+ TAINT_FLAG(FIRMWARE_WORKAROUND, 'I', ' '),
+ TAINT_FLAG(OOT_MODULE, 'O', ' '),
+ TAINT_FLAG(UNSIGNED_MODULE, 'E', ' '),
+ TAINT_FLAG(SOFTLOCKUP, 'L', ' '),
+ TAINT_FLAG(LIVEPATCH, 'K', ' '),
+ TAINT_FLAG(AUX, 'X', ' '),
+ TAINT_FLAG(RANDSTRUCT, 'T', ' '),
+ TAINT_FLAG(TEST, 'N', ' '),
+ TAINT_FLAG(FWCTL, 'J', ' '),
};
#undef TAINT_FLAG
base-commit: aaa9c3550b60d6259d6ea8b1175ade8d1242444e
--
2.51.1
^ permalink raw reply related
* Re: [PATCH v6 17/17] modsign: Enable ML-DSA module signing
From: Petr Pavlu @ 2025-10-21 13:51 UTC (permalink / raw)
To: David Howells
Cc: Eric Biggers, Jason A . Donenfeld, Ard Biesheuvel, Herbert Xu,
Stephan Mueller, Lukas Wunner, Ignat Korchagin, Luis Chamberlain,
Daniel Gomez, Sami Tolvanen, linux-crypto, keyrings,
linux-modules, linux-kernel
In-Reply-To: <20251017144311.817771-18-dhowells@redhat.com>
On 10/17/25 4:43 PM, David Howells wrote:
> 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.
This update looks ok to me. However, I'll note some problems that
I noticed in the original text, notably:
The text doesn't match the implementation because kernel/module/Kconfig
still allows selecting SHA-1 for module signing. What happened is that
commit 16ab7cb5825f ("crypto: pkcs7 - remove sha1 support") initially
removed CONFIG_MODULE_SIG_SHA1. Then, commit f2b88bab69c8
("Documentation/module-signing.txt: bring up to date") removed it from
the documentation. However, commit 203a6763ab69 ("Revert "crypto: pkcs7
- remove sha1 support"") brought back CONFIG_MODULE_SIG_SHA1 without
reverting the documentation update.
Another problem is that for MODULE_SIG_KEY_TYPE_ECDSA, certs/Kconfig
contains the line
"depends on !(MODULE_SIG_SHA256 || MODULE_SIG_SHA3_256)",
which intends to allow ECDSA only with MODULE_SIG_SHA384,
MODULE_SIG_SHA512, MODULE_SIG_SHA3_384 and MODULE_SIG_SHA3_512. This
restriction was added in commit d4f5bfe20da9 ("certs: Limit
MODULE_SIG_KEY_TYPE_ECDSA to SHA384 or SHA512") and 446b1e0b7b39
("module: enable automatic module signing with FIPS 202 SHA-3").
However, the documentation suggests that ECDSA can still be used with
SHA-2/3 of size 256.
I'll prepare fixes for these issues. For the first problem, I think we
can drop CONFIG_MODULE_SIG_SHA1 instead of correcting the documentation.
>
>
> ==========================
> @@ -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..a09db4b2c87c 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) 87 key (NIST FIPS 204) for module signing
> + with a SHAKE256 'hash' of the message.
Copy-and-paste error in the help message: 87 -> 44.
> +
> +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) 87 key (NIST FIPS 204) for module signing
> + with a SHAKE256 'hash' of the message.
Similarly here: 87 -> 65.
> +
> +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.
> +
Should all MODULE_SIG_KEY_TYPE_ML_DSA_* options depend on
MODULE_SIG_SHAKE256 to match the updated
Documentation/admin-guide/module-signing.rst?
Similarly, do MODULE_SIG_KEY_TYPE_RSA and MODULE_SIG_KEY_TYPE_ECDSA
require any "depends on" update with respect to the addition of
MODULE_SIG_SHAKE256?
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH v2 00/10] scalable symbol flags with __kflagstab
From: Petr Pavlu @ 2025-10-21 8:35 UTC (permalink / raw)
To: Siddharth Nayyar, corbet
Cc: arnd, gprocida, linux-arch, linux-kbuild, linux-kernel,
linux-modules, maennich, mcgrof, nathan, nicolas.schier,
samitolvanen
In-Reply-To: <20251020224317.723069-1-sidnayyar@google.com>
On 10/21/25 12:43 AM, Siddharth Nayyar wrote:
> On Mon, Oct 13, 2025 at 8:02PM Jonathan Corbet <corbet@lwn.net> wrote:
>> I ask "how it will be used" since you don't provide any way to actually
>> mark exports with this new flag. What is the intended usage here?
>
> Patch 09/10 (last hunk) provides a mechanism to enable import protection
> for all symbols exported by vmlinux. To summarise, modpost enables
> import protection when CONFIG_UNUSED_KSYMS_WHITELIST is set. This
> results in all symbols except for the ones mentioned in the whitelist to
> be protected from being imported by out-of-tree modules. In other words,
> out-of-tree modules can only use symbols mentioned in
> CONFIG_UNUSED_KSYMS_WHITELIST, when the config option is set.
>
> I realise I should have documented this behaviour, both in the cover
> letter as well as in kernel documentation. I will do so in the following
> version of the patch series.
>
> Please share any feedback on the mechnism to enable the mechanism. In my
> opinion, CONFIG_UNUSED_KSYMS_WHITELIST has a complementary goal to
> import protection and therefore I felt like using the option to enable
> import protection. In case this seems to convoluted, I am okay with
> introducing an explicit option to enable import protection.
CONFIG_UNUSED_KSYMS_WHITELIST was originally added in commit
1518c633df78 ("kbuild: allow symbol whitelisting with
TRIM_UNUSED_KSYMS"), specifically for Android. Looking at configs of
several distributions [1], it appears that it has only been used by
Android so far. This means it is likely acceptable to protect the
whitelist symbols in this manner.
On the other hand, I think what is protected (all exported symbols or
CONFIG_UNUSED_KSYMS_WHITELIST) and how it is protected
(KSYM_FLAG_PROTECTED) are two different things, so it might be cleaner
to keep them separate.
>
>> If I understand things correctly, applying this series will immediately
>> result in the inability to load any previously built modules, right?
>> That will create a sort of flag day for anybody with out-of-tree modules
>> that some may well see as a regression. Is that really the intent?
>
> Unfortunately this series will break all modules which export symbols
> since older versions of such modules will not have the kflagstab
> section.
I would add that out-of-tree modules are typically leaves that don't
export any symbols. This means it should still be possible to load such
modules on an updated kernel.
A problem occurs when out-of-tree support is split into multiple
modules, where one module exports data for another. Some drivers can be
split in such a way. For example, a NIC driver might be divided into
core, Ethernet and InfiniBand modules, where the core provides exports
for the latter modules.
In such a case, the kernel will ignore the __ksymtab_gpl section in the
first module and issue a warning about it (patch #6). Eventually, when
the second module is attempted to be inserted, the load operation will
result in an error due to an unresolved import.
In practice, I believe this series should have limited impact. Stable
trees and distributions that care about kABI stability should not
backport it. In contrast, people who follow master releases typically
don't use out-of-tree modules, or they know how to deal with updating
them. In this case, only recompilation is needed, which is less
impactful than when an API changes and the actual module code needs to
be updated.
In the past, there were already breaking changes to the format of the
exported data, notably in commit 7290d5809571 ("module: use relative
references for __ksymtab entries") and 8651ec01daed ("module: add
support for symbol namespaces."). As far as I'm aware, these changes
didn't cause significant trouble, even though they actually resulted in
silent breakages of old modules with exports.
>
> Out-of-tree modules which do not export symbols of their own will only
> fail to load in case the CONFIG_UNUSED_KSYMS_WHITELIST is set and the
> symbols which these modules consume are not present in the whitelist.
[1] https://oracle.github.io/kconfigs/?config=UTS_RELEASE&config=UNUSED_KSYMS_WHITELIST
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH v2 3/3] module: Add compile-time check for embedded NUL characters
From: Aaron Tomlin @ 2025-10-21 2:05 UTC (permalink / raw)
To: Kees Cook
Cc: Luis Chamberlain, Rusty Russell, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, linux-modules, Hans Verkuil, Malcolm Priestley,
Mauro Carvalho Chehab, Hans Verkuil, Uwe Kleine-König,
linux-kernel, linux-media, linux-hardening
In-Reply-To: <20251010030610.3032147-3-kees@kernel.org>
On Thu, Oct 09, 2025 at 08:06:09PM -0700, Kees Cook wrote:
> Long ago, the kernel module license checks were bypassed by embedding a
> NUL character in the MODULE_LICENSE() string[1]. By using a string like
> "GPL\0proprietary text", the kernel would only read "GPL" due to C string
> termination at the NUL byte, allowing proprietary modules to avoid kernel
> tainting and access GPL-only symbols.
>
> The MODULE_INFO() macro stores these strings in the .modinfo ELF
> section, and get_next_modinfo() uses strcmp()-family functions
> which stop at the first NUL. This split the embedded string into two
> separate .modinfo entries, with only the first part being processed by
> license_is_gpl_compatible().
>
> Add a compile-time check using static_assert that compares the full
> string length (sizeof - 1) against __builtin_strlen(), which stops at
> the first NUL. If they differ, compilation fails with a clear error
> message.
>
> While this check can still be circumvented by modifying the ELF binary
> post-compilation, it prevents accidental embedded NULs and forces
> intentional abuse to require deliberate binary manipulation rather than
> simple source-level tricks.
>
> Build tested with test modules containing both valid and invalid license
> strings. The check correctly rejects:
>
> MODULE_LICENSE("GPL\0proprietary")
>
> while accepting normal declarations:
>
> MODULE_LICENSE("GPL")
>
> Link: https://lwn.net/Articles/82305/ [1]
> Suggested-by: Rusty Russell <rusty@rustcorp.com.au>
> Signed-off-by: Kees Cook <kees@kernel.org>
> ---
> Cc: Luis Chamberlain <mcgrof@kernel.org>
> Cc: Petr Pavlu <petr.pavlu@suse.com>
> Cc: Daniel Gomez <da.gomez@kernel.org>
> Cc: Sami Tolvanen <samitolvanen@google.com>
> Cc: <linux-modules@vger.kernel.org>
> ---
> include/linux/moduleparam.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
> index 6907aedc4f74..915f32f7d888 100644
> --- a/include/linux/moduleparam.h
> +++ b/include/linux/moduleparam.h
> @@ -26,6 +26,9 @@
>
> /* Generic info of form tag = "info" */
> #define MODULE_INFO(tag, info) \
> + static_assert( \
> + sizeof(info) - 1 == __builtin_strlen(info), \
> + "MODULE_INFO(" #tag ", ...) contains embedded NUL byte"); \
> static const char __UNIQUE_ID(modinfo)[] \
> __used __section(".modinfo") __aligned(1) \
> = __MODULE_INFO_PREFIX __stringify(tag) "=" info
> --
> 2.34.1
>
>
Nice!
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
--
Aaron Tomlin
^ 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