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 implements temporal
boundary checks to prevent use-after-free (UAF) risks when loading
dynamic modules, and a fast-path check to eliminate lookup overhead
during boot 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
include/asm-generic/vmlinux.lds.h | 4 ++-
include/linux/init.h | 24 +++++++++++++++-
include/linux/module.h | 5 +++-
init/main.c | 47 +++++++++++++++++++++++++++++++
kernel/module/main.c | 24 ++--------------
5 files changed, 79 insertions(+), 25 deletions(-)
--
2.54.0
