On Sun, Mar 19, 2023 at 02:35:37PM -0700, Luis Chamberlain wrote: > While doing a cleanup of load_module() to do less work before we allocate [0], > one of the undocumented tricks we pull off is memcpy'ing the struct module > from the module.mod.c into the kernel, with the modifications we've made > to it on load_module(). This puts a bit of love to make the clearer, and > extends our ELF validity checker to ensure we verify this before allowing > us to even process a module. > > This effort has discovered a new possible build issue we have to fix: > > It is in theory possible today to modify the module struct module size, > let a kernel developer lazily just build the module (say make fs/xfs/) > and then try to insert that module without ensuring the module size > expected should have grown. You can verify the size with: > > nm --print-size --size-sort fs/xfs/xfs.ko | grep __this_module > 0000000000000000 0000000000000500 D __this_module > > The struct module size will be different per each kernel configuration, > and so this is system build dependent. The new ELF check put in place > prevents this situation and also make the use case of memcpying the > struct module very clear, along with ensuring we keep all modifications > we've made to it. > > [0] https://lkml.kernel.org/r/20230311051712.4095040-1-mcgrof@xxxxxxxxxx I've taken these into modules-next for more testing. If folks spot issues in them though let me know and I can yank them before the merge window. Luis
