linux-kernel - Re: [PATCH 00/12] module: cleanup and call taints after is inserted

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 22 Mar 2023 16:42:34 -0700
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     linux-modules@...r.kernel.org, linux-kernel@...r.kernel.org,
        pmladek@...e.com, david@...hat.com, petr.pavlu@...e.com,
        prarit@...hat.com
Cc:     christophe.leroy@...roup.eu, song@...nel.org
Subject: Re: [PATCH 00/12] module: cleanup and call taints after is inserted

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