public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Luis Chamberlain <mcgrof@kernel.org>
To: linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org,
	pmladek@suse.com, david@redhat.com, petr.pavlu@suse.com,
	prarit@redhat.com
Cc: christophe.leroy@csgroup.eu, song@kernel.org, mcgrof@kernel.org
Subject: [PATCH 0/5] module: ELF validation enhancement and cleanups
Date: Sun, 19 Mar 2023 14:35:37 -0700	[thread overview]
Message-ID: <20230319213542.1790479-1-mcgrof@kernel.org> (raw)

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%)

-- 
2.39.1


             reply	other threads:[~2023-03-19 21:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-19 21:35 Luis Chamberlain [this message]
2023-03-19 21:35 ` [PATCH 1/5] module: add sanity check for ELF module section Luis Chamberlain
2023-03-19 21:35 ` [PATCH 2/5] module: add stop-grap sanity check on module memcpy() Luis Chamberlain
2023-03-19 21:35 ` [PATCH 3/5] module: move more elf validity checks to elf_validity_check() Luis Chamberlain
2023-03-19 21:35 ` [PATCH 4/5] module: merge remnants of setup_load_info() to elf validation Luis Chamberlain
2023-03-19 21:35 ` [PATCH 5/5] module: fold usermode helper kmod into modules directory Luis Chamberlain
2023-03-22 23:43 ` [PATCH 0/5] module: ELF validation enhancement and cleanups Luis Chamberlain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230319213542.1790479-1-mcgrof@kernel.org \
    --to=mcgrof@kernel.org \
    --cc=christophe.leroy@csgroup.eu \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=petr.pavlu@suse.com \
    --cc=pmladek@suse.com \
    --cc=prarit@redhat.com \
    --cc=song@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox