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

[Petr Pavlu <petr.pavlu@suse.com>]

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/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.

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.

[1] https://lore.kernel.org/linux-modules/610fc63b-f3dc-4824-99fd-907fc96f3194@oracle.com/

-- 
Cheers,
Petr