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

On Fri, Aug 14, 2026 at 01:16:01PM +0200, Petr Pavlu wrote:
> On 8/13/26 4:50 PM, Gary Guo wrote:
> > 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.
> 
> I can imagine this being possible and potentially useful. For instance,
> a minimal `struct module` could be used for each built-in and loadable
> module. For the latter, it could be then extended to something like
> `struct loadable_module` containing all the fields currently needed for
> loadable modules.
> 
> It could also help improve some C APIs. Functions currently cannot
> determine whether a NULL value passed as a module parameter indicates an
> invalid pointer or a built-in module [1].
> 
> > 
> > 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.
> 
> I agree this looks non-trivial. It would require proper investigation to
> see how it might actually turn out.

Hi Gary, Petr,

Thanks for the interesting discussion and ideas.

I agree that unifying built-in and loadable modules under a common, minimal
representation is an attractive long-term architectural concept. It would
certainly bring cleaner semantics to APIs.

However, as noted, such a unification is a non-trivial, kernel-wide
overhaul affecting core infrastructure etc.

In contrast, this series is focused on solving a specific, practical
debugging and boot configuration issue with minimal intrusion, using
metadata that is reclaimed entirely after boot.

Given the substantial difference in scope, I believe it would be best to
keep this series focused on the immediate blacklist/denylist functionality
and defer the broader module representation investigation for future work.


Kind regards,
-- 
Aaron Tomlin