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
