On Mon, Jun 22, 2026 at 10:02:59AM -0400, Aaron Tomlin wrote:
> Currently, the module_blacklist= parameter only prevents
> the dynamic loading of external modules. It possesses no mechanism to
> intercept or prevent the initialisation of built-in modules, as their
> associated initcalls are invoked unconditionally during system boot.
>
> This patch extends the blacklisting behaviour to encompass built-in
> modules. It introduces a dedicated ".initcall.modnames" section into
> the linker script, systematically mapping each initcall to its
> originating module name. During the boot sequence, do_one_initcall()
> interrogates this mapping; should the executing initcall belong to a
> blacklisted module, its execution is explicitly bypassed.
Hi Arnd, Luis, Petr, Daniel, Sami,
Sashiko [1] correctly reported issues with this version. Consequently,
in the next iteration, I will implement the following changes:
1. Abandon the raw assembly approach in favour of using standard C
structures (i.e., struct initcall_modname). While this sacrifices
the PREL32 relative offset optimisation for this specific table, it
guarantees architectural safety and ensures native compiler support
for both LTO and CFI.
2. Wrap the module_is_blacklisted declaration in the necessary #ifdef
CONFIG_MODULES guards to prevent undefined reference errors when
loadable module support is disabled.
3. Iterating over .initcall.modnames within the shared
do_one_initcall() path introduces a severe UAF vulnerability when
loadable modules are initialised post-boot. To rectify this, I will
introduce a strict, read-only flag (initmem_freed) to explicitly
bypass the built-in lookup once free_initmem() has reclaimed the
.init sections. Furthermore, to maintain a clean separation of
concerns, the blacklist check for loadable modules will be migrated
directly into the module loader path (do_init_module()).
[1]: https://sashiko.dev/#/patchset/20260622140259.2974-1-atomlin%40atomlin.com
Kind regards,
--
Aaron Tomlin
