mbox series

[00/12] module: cleanup and call taints after is inserted

Message ID 20230319212746.1783033-1-mcgrof@kernel.org (mailing list archive)
Headers show
Series module: cleanup and call taints after is inserted | expand

Message

Luis Chamberlain March 19, 2023, 9:27 p.m. UTC
After posting my first RFC for "module: avoid userspace pressure on unwanted
allocations" [0] I ended up doing much more cleanup on the module loading path.
One of the things that became evident while ensuring we do *less* work before
kmalloc all the things we need for the final module is we are doing a lot of
work before we even add a module onto our linked list, once its accepted for
loading and running init. We even *taint* the kernel even before we accept
a module. We also do some tainting after kernel loading.

This converges both to one point -- right as soon as we accept module
into our linked list. That is, the module is valid as per our kernel
config and we're ready to go. Most of this is just tidying code up. The
biggest functional changes is under the patch "converge taint work together".

I'll post the other functional changes in two other patch sets. This is
mostly cleanup, the next one is the new ELF checks / sanity / cleanup,
and I'm waiting to hear back from David Hildenbrand on the worthiness of
some clutches for allocation. That last part would go in the last patch
series.

In this series I've dropped completely the idea of using aliasing since
different modules can share the same alias, so using that to check if
a module is already loaded turns out not to be useful in any way.

[0] https://lkml.kernel.org/r/20230311051712.4095040-1-mcgrof@kernel.org

Luis Chamberlain (12):
  module: move get_modinfo() helpers all above
  module: rename next_string() to module_next_tag_pair()
  module: add a for_each_modinfo_entry()
  module: move early sanity checks into a helper
  module: move check_modinfo() early to early_mod_check()
  module: rename set_license() to module_license_taint_check()
  module: split taint work out of check_modinfo_livepatch()
  module: split taint adding with info checking
  module: move tainting until after a module hits our linked list
  module: move signature taint to module_augment_kernel_taints()
  module: converge taint work together
  module: rename check_module_license_and_versions() to
    check_export_symbol_versions()

 kernel/module/internal.h |   5 +
 kernel/module/main.c     | 292 ++++++++++++++++++++-------------------
 2 files changed, 158 insertions(+), 139 deletions(-)

Comments

Luis Chamberlain March 22, 2023, 11:42 p.m. UTC | #1
On Sun, Mar 19, 2023 at 02:27:34PM -0700, Luis Chamberlain wrote:
> After posting my first RFC for "module: avoid userspace pressure on unwanted
> allocations" [0] I ended up doing much more cleanup on the module loading path.
> One of the things that became evident while ensuring we do *less* work before
> kmalloc all the things we need for the final module is we are doing a lot of
> work before we even add a module onto our linked list, once its accepted for
> loading and running init. We even *taint* the kernel even before we accept
> a module. We also do some tainting after kernel loading.
> 
> This converges both to one point -- right as soon as we accept module
> into our linked list. That is, the module is valid as per our kernel
> config and we're ready to go. Most of this is just tidying code up. The
> biggest functional changes is under the patch "converge taint work together".
> 
> I'll post the other functional changes in two other patch sets. This is
> mostly cleanup, the next one is the new ELF checks / sanity / cleanup,
> and I'm waiting to hear back from David Hildenbrand on the worthiness of
> some clutches for allocation. That last part would go in the last patch
> series.
> 
> In this series I've dropped completely the idea of using aliasing since
> different modules can share the same alias, so using that to check if
> a module is already loaded turns out not to be useful in any way.
> 
> [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