This patch series extends the module_blacklist= command-line parameter (and
its modern alias module_denylist=) to intercept built-in modules during
early boot. Currently, when a driver is compiled statically into the kernel
(=y), the parameter is silently ignored, precluding administrators from
suppressing problematic drivers during boot-time disaster recovery. This
series resolves that discrepancy by mapping built-in modules to their
initialisation routines via transient metadata that is freed post-boot,
providing a predictable and consistent administrative interface regardless
of whether a driver is built as a loadable module or compiled into the
kernel image. Below is a detailed breakdown of the motivation, operational
rationale, and concrete use cases addressed by this work.
1. The Core Problem and User Experience Gap
============================================
Today, module_blacklist= works strictly on loadable modules. When a user or
system administrator encounters a driver bug, hang during device probe, or
hardware fault during boot, the natural and widely documented remedy is to
pass module_blacklist=[driver] via the bootloader (GRUB, systemd-boot,
etc.). However, if that driver is built into the kernel, the parameter is
silently ignored. The kernel proceeds to run the driver's initialisation
routine anyway, leading to the same panic, hang, or hardware misbehaviour.
>From the user's standpoint, whether a driver was packaged by their
distribution or built by their provider as =m or =y is an internal
implementation detail. Having module_blacklist= silently fail solely based
on compilation configuration violates the principle of least surprise and
complicates system recovery.
2. Why initcall_blacklist= is not an adequate substitute
=========================================================
The kernel does provide initcall_blacklist=, but it is impractical for
general users, sysadmins, and automated fleet management tools for several
reasons:
Obscure symbol names
- initcall_blacklist= requires the exact function name of the
initcall (e.g., snb_pci_uarch_init and e1000_init_module). Users
typically know the module name, not the internal function name.
Internal instability
- Initcall function names are internal kernel implementation
details. They change across kernel releases, refactors, or macro
rewrites, making it impossible to write stable bootloader
configurations or recovery documentation across multiple kernel
versions.
Mangled names (Rust)
- For modern drivers written in Rust, the initcall symbol names are
compiler-mangled symbols (e.g. "_RNvX"), making
initcall_blacklist= practically impossible for a human user to
specify manually at a boot prompt.
module_blacklist= (or module_denylist=) resolves this by allowing users to
specify the canonical, user-facing module name (KBUILD_MODNAME) that they
already know.
3. Concrete use cases
======================
A. Disaster recovery and triage on production systems
When a kernel update introduces a regression in a built-in driver
(e.g., a storage controller), administrators need a way to bypass
that driver at boot time to get the system into a usable emergency
shell or collect diagnostic logs, without having to rebuild the
kernel on another machine.
B. Monolithic/Hardened environments (CONFIG_MODULES=n)
In security-sensitive environments, kernels are frequently compiled
without loadable module support (CONFIG_MODULES=n) to eliminate
module loading attack vectors. On these systems, all drivers are
built-in. If a hardware erratum or firmware bug triggers a hang in
a built-in driver, administrators previously had no
module-name-based mechanism to disable the offending driver.
C. Hardware Errata and Conflicting Devices
On systems with buggy firmware or conflicting device IDs where two
drivers attempt to bind to the same hardware, users can prevent the
conflicting built-in driver from initializing without patching and
recompiling the entire kernel image.
4. Implementation and Overhead Considerations
=============================================
We took great care to ensure this change introduces virtually zero runtime
overhead:
Scoped to module_init()
- Only built-in drivers that explicitly use module_init() are
tracked. Core kernel subsystems using core_initcall(),
subsys_initcall(), etc. are unaffected.
Zero Resident Memory
- The metadata table (.initcall.modnames) and the module name
strings (.init.rodata) are placed entirely in init sections and
are completely freed from memory after boot via free_initmem().
Fast Path
- During boot, if neither module_blacklist= nor module_denylist=
was supplied on the kernel command line, the lookup is bypassed
entirely.
In summary, this patch brings parity between modular and built-in drivers,
removes a pain point in boot-time disaster recovery, and provides users
with a predictable, consistent interface.
Following review feedback, the implementation is structured as three
separate changes to isolate a pre-existing bugfix, decouple the
introduction of the new feature, and handle the terminology renaming:
1. The first patch is a standalone prerequisite bugfix addressing a
pre-existing flaw in the module blacklisting logic where hyphens
and underscores are not treated interchangeably. Because the kernel
build system normalises module names to use underscores (e.g.
"my_module"), specifying a module with hyphens on the command line
(such as "module_blacklist=my-module") failed to match due to a
strict byte-for-byte memcmp(). It replaces memcmp() with
parameqn(), carries a Fixes: tag, and is CC'd to stable.
2. The second 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.
3 The third 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.
Changes since v10:
- Introduced a standalone prerequisite patch to treat dashes and
underscores interchangeably in module_blacklist= via parameqn()
- Added '. = ALIGN(8);' before BOUNDED_SECTION_BY(.initcall.modnames, ...)
in include/asm-generic/vmlinux.lds.h to ensure the location counter is
explicitly 8-byte aligned before the start label is captured
- Fixed a build failure for built-in Rust modules in rust/macros/module.rs
by using Literal::byte_string() to initialize the static byte array in
.init.rodata, avoiding an unsized slice dereference (*(&[u8]))
- Expanded the cover letter to detail the background, operational
rationale, and concrete use cases for built-in module denylisting
(Andrew Morton)
- Link to v10:
https://lore.kernel.org/all/[email protected]/
Changes since v9:
- Enforced natural structure alignment on struct initcall_modname in
include/linux/init.h via __aligned(__alignof__(struct initcall_modname))
to prevent compiler over-alignment and inter-element linker padding
(Petr Pavlu)
- Removed STRUCT_ALIGN() before BOUNDED_SECTION_BY(.initcall.modnames,
_initcall_modnames) to eliminate unnecessary alignment (Petr Pavlu)
- Added <linux/init.h> to rust/bindings/bindings_helper.h and updated
rust/macros/module.rs to use the generated
::kernel::bindings::initcall_modname struct rather than a locally
defined type (Gary Guo and Petr Pavlu)
- Placed the Rust module name string explicitly in .init.rodata within
rust/macros/module.rs (#[link_section = ".init.rodata"]) so that the
string memory is reclaimed alongside the initcall table after boot,
matching the C implementation (Petr Pavlu)
- Link to v9:
https://lore.kernel.org/lkml/[email protected]/
Changes since v8:
- Extended Rust procedural macro support in rust/macros/module.rs to
generate .initcall.modnames metadata for built-in Rust modules,
maintaining feature parity with C built-in modules when evaluating
"module_blacklist=" and "module_denylist=" (Petr Pavlu)
- Merged the intermediate ___define_initcall_modname macro directly into
__define_initcall_modname in include/linux/init.h to clean up macro
expansion (Petr Pavlu)
- Reverted the parameter name in module_init(x) back to 'x' in
include/linux/module.h to remain consistent with surrounding comments
(Petr Pavlu)
- Cleaned up whitespace formatting in kernel/module/main.c (Petr Pavlu)
- Link to v8:
https://lore.kernel.org/lkml/[email protected]/
Changes since v7:
- Fixed a double evaluation of __initcall_id(fn) in the built-in module
initcall macro expansion
- Link to v7:
https://lore.kernel.org/lkml/[email protected]/
Changes since v6:
- Grouped the __initcall_fn_ptr() macro definition inside the existing
CONFIG_HAVE_ARCH_PREL32_RELOCATIONS block in include/linux/init.h
(Petr Pavlu)
- Localised the built-in module initcall level and section naming strictly
to include/linux/init.h by introducing the macros
__define_initcall_modname() and __builtin_module_initcall(), keeping
include/linux/module.h clean (Petr Pavlu)
- Removed the unnecessary dereference_function_descriptor() lookup wrapper
in get_builtin_modname() in favour of a direct pointer comparison
(Petr Pavlu)
- Cleaned up whitespace formatting in kernel/module/main.c (Petr Pavlu)
- Link to v6:
https://lore.kernel.org/lkml/[email protected]/
Changes since v5:
- Resolved a modpost cross-section mismatch warning by introducing
do_one_initcall_builtin() as a strict __init wrapper function, rather
than performing the built-in module checks inside the __init_or_module
do_one_initcall() function
- Addressed a UAF race condition with concurrent dynamic module loading by
strictly bounding the blacklist evaluation to early boot via the new
__init wrapper, removing temporal check
- Mitigated a potential Spectre v1 speculative execution vulnerability by
ensuring get_builtin_modname() is exclusively called by __init code,
preventing unprivileged runtime module loading from speculatively
jumping into reclaimed ".init.text" instructions
- Updated Documentation/admin-guide/kernel-parameters.txt to explicitly
mark "module_blacklist=" as deprecated and document "module_denylist="
- Link to v5:
https://lore.kernel.org/lkml/[email protected]/
Changes since v4:
- Split the monolithic patch into two distinct commits. One to extend the
functionality to built-in modules, and a second to safely transition the
internal terminology to "denylist" (Arnd Bergmann)
- Preserved "module_blacklist=" as a legacy core_param alias in the second
commit to ensure backwards compatibility with existing userspace
configurations
- Restricted the population of the ".initcall.modnames" section strictly
to module_init() rather than all ___define_initcall() invocations. This
prevents non-module core initcalls from being redundantly mapped, saving
memory and avoiding false-positive matches (Petr Pavlu)
- Introduced a fast-path evaluation to check if the blacklist/denylist is
actually populated before invoking get_builtin_modname(), avoiding
unnecessary lookups during boot (Petr Pavlu)
- Link to v4:
https://lore.kernel.org/lkml/[email protected]/
Changes since v3:
- Renamed the external function prototype and internal helper to
module_is_denylisted(), while updating the backing variable in
main.c to module_denylist. To preserve user-space compatibility
while adopting modern terminology, separate core_param entries have
been introduced, allowing both the preferred module_denylist=
parameter and the legacy module_blacklist= parameter to resolve to
the same underlying variable (Andrew Morton)
- I introduced the __initcall_fn_ptr() macro helper to dynamically
resolve the initcall pointer configuration:
- For architectures with relative 32-bit relocations
(CONFIG_HAVE_ARCH_PREL32_RELOCATIONS=y), it resolves to the
relocation stub pointer __initcall_stub(fn, __iid, id)
- For architectures without PREL32 relocations, it resolves
directly to the function pointer fn
- Decoupled the module_denylist parameter parsing and the
module_is_denylisted() function from CONFIG_MODULES, moving the
logic to init/main.c. This ensures the denylist works for built-in
modules even on monolithic kernels built without loadable module
support (CONFIG_MODULES=n)
- Removed the conditional stub implementation of
module_is_denylisted() in module.h and replaced it with a single,
unconditional declaration outside of the #ifdef CONFIG_MODULES block.
This prevents compiler warnings about missing prototypes and ensures
visibility under a monolithic configuration
- Replaced the initmem_freed state variable and its synchronisation
logic in kernel_init() with race-free spatial boundary checks using
is_kernel_text() and is_kernel_inittext() in initcall_get_modname()
- Aligned the .initcall_modnames table with relocations by assigning
.initcall_fn using the __initcall_stub() helper in
___define_initcall(). This ensures the lookup matches the actual stub
pointer passed to do_one_initcall() when
CONFIG_HAVE_ARCH_PREL32_RELOCATIONS is enabled. Passed the preprocessor
__iid argument to ____define_initcall_modname once to avoid double
evaluation of __COUNTER__ (which caused build failures with LTO)
- Updated initcall_get_modname() in main.c to resolve the function
pointer fn using dereference_function_descriptor(fn) prior to
checking the .text and .init.text boundaries, and dereference both
fn and p->initcall_fn in the comparison loop to support descriptor-based
architectures (e.g., PPC64)
- Link to v3:
https://lore.kernel.org/lkml/[email protected]/
Changes since v2:
- Avoided relative 32-bit offsets (PREL32) with inline assembly, opting
instead for standard C structures with absolute pointers. This fixes LTO
and CFI compatibility issues (e.g., under Clang) where raw inline assembly
fails to track compiler-generated symbols and CFI stubs
- Placed module name strings into the ".init.rodata" section via a dedicated
static array to ensure they are freed from memory after boot
- Avoided Use-After-Free (UAF) bugs post-boot when loading dynamic modules:
- Added an 'initmem_freed' flag, marked as '__ro_after_init', set after
free_initmem() to skip table lookups for dynamically loaded modules
- Added a blacklist check in do_init_module() for dynamic modules
- Simplified the linker script using the BOUNDED_SECTION_PRE_LABEL() macro
to define the ".initcall.modnames" section boundary
- Added a dummy/stub implementation of module_is_blacklisted() when
CONFIG_MODULES is disabled to avoid build errors
- Link to v2:
https://lore.kernel.org/lkml/[email protected]/
Changes since v1:
- Pivoted entirely from exposing built-in initcalls and their blacklist
status via a debugfs interface to directly extending the existing
"module_blacklist=" and new "module_blacklist=" to intercept built-in
modules at boot (Petr Pavlu)
- Implemented 32-bit relative offsets (CONFIG_HAVE_ARCH_PREL32_RELOCATIONS)
to store the mappings, preventing binary bloat and preserving KASLR
efficacy
- Link to v1:
https://lore.kernel.org/lkml/[email protected]/
Aaron Tomlin (3):
module: Treat dashes and underscores interchangeably in
module_blacklist
module: Extend module_blacklist parameter to built-in modules
module: Rename module_blacklist to module_denylist
.../admin-guide/kernel-parameters.txt | 6 +-
include/asm-generic/vmlinux.lds.h | 4 +-
include/linux/init.h | 25 ++++++++-
include/linux/module.h | 4 +-
init/main.c | 55 ++++++++++++++++++-
kernel/module/main.c | 24 +-------
rust/bindings/bindings_helper.h | 1 +
rust/macros/module.rs | 19 +++++++
8 files changed, 110 insertions(+), 28 deletions(-)
--
2.55.0
