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. [1] https://lore.kernel.org/linux-modules/[email protected]/ -- Cheers, Petr
