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

["Gary Guo" <gary@garyguo.net>]

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/20260421-acpi_mod_name-v2-0-e73f9310dad3@sony.com/
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(-)