Re: [PATCH v9 0/2] module: Extend module_blacklist parameter to built-in modules

"Gary Guo" <[email protected]>
Newsgroups org.kernel.vger.linux-arch,org.kernel.vger.linux-kernel,org.kernel.vger.linux-modules,org.kernel.vger.rust-for-linux
Message-ID <[email protected]>
On Fri Aug 7, 2026 at 2:25 AM BST, Aaron Tomlin wrote:
> Currently, the "module_blacklist=" command-line parameter only applies to
> loadable modules. If a module is built-in, the parameter is silently
> ignored. This patch series extends the blacklisting functionality to
> built-in modules by intercepting their initialisation routines during early
> boot.
>
> Following review feedback, the implementation has been split into two
> separate changes to decouple the introduction of the new feature from the
> terminology renaming:
>
>     1.  The first patch extends the "module_blacklist=" parameter to
>         built-in modules using the original blacklist terminology. It
>         introduces the ".initcall.modnames" section to map initcall
>         function pointers to their associated KBUILD_MODNAME strings
>         (restricted only to module_init() invocations to save memory and
>         avoid matching core kernel subsystems). It also restricts the check
>         to a boot-time __init wrapper to eliminate Use-After-Free (UAF) and
>         Spectre v1 vulnerability risks when loading dynamic modules at
>         runtime, and adds a fast-path check to eliminate lookup overhead
>         when the parameter is not in use
>
>     2.  The second patch renames the variables and helper functions to
>         adopt the preferred "module_denylist=" and module_is_denylisted()
>         terminology in the codebase. To preserve the existing user-space
>         ABI, "module_blacklist=" is kept as a legacy alias pointing to the
>         same module_denylist variable
>
> Aaron Tomlin (2):
>   module: Extend module_blacklist parameter to built-in modules
>   module: Rename module_blacklist to module_denylist

I feel with
https://lore.kernel.org/driver-core/[email protected]/
and this we're really making loadable module and builtin modules less different.

I wonder if we should just somewhat unify these completly, so built-in modules
just behave identically to loadable modules, just without runtime relocations
and ability to unload.

Of course, that's quite a big change... And mostly likely people won't care
because almost everything is built as loadable modules in distros anyway.

Best,
Gary

>
>  .../admin-guide/kernel-parameters.txt         |  6 +-
>  include/asm-generic/vmlinux.lds.h             |  4 +-
>  include/linux/init.h                          | 24 +++++++-
>  include/linux/module.h                        |  4 +-
>  init/main.c                                   | 55 ++++++++++++++++++-
>  kernel/module/main.c                          | 25 +--------
>  rust/macros/module.rs                         | 16 ++++++
>  7 files changed, 105 insertions(+), 29 deletions(-)
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.