Re: [PATCH v8 0/2] module: Rename module_blacklist to module_denylist

[Aaron Tomlin]

On Thu, Jul 23, 2026 at 10:47:42PM -0400, 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

Hi Petr,

Please note that the subject of this cover letter should read: "module:
Extend module_blacklist parameter to built-in modules". This iteration
should address all of your concerns raised [1]. Thank you.

[1]: https://lore.kernel.org/lkml/2cada244-171d-45cb-a6f0-46e6a09375c7@xxxxxxxx/

Kind regards,
-- 
Aaron Tomlin