On Sun, May 10, 2026 at 02:13:01AM -0400, Aaron Tomlin wrote: > At present, identifying the correct function name to supply to the > "initcall_blacklist=" kernel command-line parameter requires manual > inspection of the source code or kernel symbol tables. Furthermore, > administrators lack a reliable runtime mechanism to verify whether a > specified built-in module has been successfully blacklisted. > > To resolve this, introduce a new debugfs interface at > /sys/kernel/debug/modules/builtin_initcalls. This file enumerates all > built-in modules alongside their corresponding initialisation callbacks > (e.g., those specified by module_init()) in a simple format: > "module_name init_callback". If a built-in module has been actively > blacklisted, the entry is explicitly appended with a " [blacklisted]" > suffix. > > To achieve this without incurring runtime overhead, the > ___define_initcall macro is expanded to statically allocate a > builtin_initcall_record structure (containing the module and function > name strings) within a dedicated .rodata_builtin_initcall_records > section. > > This implementation incorporates several critical architectural safety > measures: > - The custom section name deliberately begins with ".rodata" to ensure > KASLR (Kernel Address Space Layout Randomisation) relocation tools > process and update the string pointers correctly during boot. > - The structural alignment is explicitly forced to 8 bytes to prevent > the compiler from inserting silent padding that would misalign the > linker script boundaries. > - The blacklisted_initcalls list head is stripped of its > __initdata_or_module annotation, ensuring the list remains safely > accessible in memory when queried from user space after early boot.
Hi Sasha, Breno, I thought this might be of interest to you for review, given your recent work and interest on the "killswitch" proposal [1]. [1]: https://lore.kernel.org/lkml/[email protected]/ Kind regards, -- Aaron Tomlin
signature.asc
Description: PGP signature
