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] [day] [month] [year] [list]
Message-ID: <ZBuShv1hx03WmzH4@bombadil.infradead.org>
Date:   Wed, 22 Mar 2023 16:43:02 -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 0/5] module: ELF validation enhancement and cleanups

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ