mbox series

[0/5] module: ELF validation enhancement and cleanups

Message ID 20230319213542.1790479-1-mcgrof@kernel.org
Headers
Series module: ELF validation enhancement and cleanups |

Message

Luis Chamberlain March 19, 2023, 9:35 p.m. UTC 
  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@kernel.org

Luis Chamberlain (5):
  module: add sanity check for ELF module section
  module: add stop-grap sanity check on module memcpy()
  module: move more elf validity checks to elf_validity_check()
  module: merge remnants of setup_load_info() to elf validation
  module: fold usermode helper kmod into modules directory

 MAINTAINERS                |  13 +--
 kernel/Makefile            |   1 -
 kernel/module/Makefile     |   4 +-
 kernel/{ => module}/kmod.c |   0
 kernel/module/main.c       | 219 ++++++++++++++++++++++++-------------
 5 files changed, 148 insertions(+), 89 deletions(-)
 rename kernel/{ => module}/kmod.c (100%)

Comments

Luis Chamberlain March 22, 2023, 11:43 p.m. UTC | #1 
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@kernel.org

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