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]
Message-ID: <20230117175144.GI16547@kitsune.suse.cz>
Date:   Tue, 17 Jan 2023 18:51:44 +0100
From:   Michal Suchánek <msuchanek@...e.de>
To:     Gary Guo <gary@...yguo.net>
Cc:     Lucas De Marchi <lucas.demarchi@...el.com>,
        Kees Cook <keescook@...omium.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        linux-kbuild@...r.kernel.org,
        Wedson Almeida Filho <wedsonaf@...gle.com>,
        Joel Stanley <joel@....id.au>,
        Alex Gaynor <alex.gaynor@...il.com>,
        Miguel Ojeda <ojeda@...nel.org>,
        Wedson Almeida Filho <wedsonaf@...il.com>,
        Nicolas Schier <nicolas@...sle.eu>,
        rust-for-linux@...r.kernel.org,
        Guo Zhengkui <guozhengkui@...o.com>,
        Boqun Feng <boqun.feng@...il.com>,
        Nicholas Piggin <npiggin@...il.com>,
        Björn Roy Baron <bjorn3_gh@...tonmail.com>,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        linux-kernel@...r.kernel.org, Julia Lawall <Julia.Lawall@...ia.fr>,
        Luis Chamberlain <mcgrof@...nel.org>,
        linuxppc-dev@...ts.ozlabs.org, linux-modules@...r.kernel.org
Subject: Re: [PATCH] modpost: support arbitrary symbol length in modversion

Hello,

On Fri, Jan 13, 2023 at 06:18:41PM +0000, Gary Guo wrote:
> On Thu, 12 Jan 2023 14:40:59 -0700
> Lucas De Marchi <lucas.demarchi@...el.com> wrote:
> 
> > On Wed, Jan 11, 2023 at 04:11:51PM +0000, Gary Guo wrote:
> > >
> > > struct modversion_info {
> > >-	unsigned long crc;
> > >-	char name[MODULE_NAME_LEN];
> > >+	/* Offset of the next modversion entry in relation to this one. */
> > >+	u32 next;
> > >+	u32 crc;
> > >+	char name[0];  
> > 
> > although not really exported as uapi, this will break userspace as this is
> > used in the  elf file generated for the modules. I think
> > this change must be made in a backward compatible way and kmod updated
> > to deal with the variable name length:
> > 
> > kmod $ git grep "\[64"
> > libkmod/libkmod-elf.c:  char name[64 - sizeof(uint32_t)];
> > libkmod/libkmod-elf.c:  char name[64 - sizeof(uint64_t)];
> > 
> > in kmod we have both 32 and 64 because a 64-bit kmod can read both 32
> > and 64 bit module, and vice versa.
> > 
> 
> Hi Lucas,
> 
> Thanks for the information.
> 
> The change can't be "truly" backward compatible, in a sense that
> regardless of the new format we choose, kmod would not be able to decode
> symbols longer than "64 - sizeof(long)" bytes. So the list it retrieves
> is going to be incomplete, isn't it?
> 
> What kind of backward compatibility should be expected? It could be:
> * short symbols can still be found by old versions of kmod, but not
>   long symbols;

That sounds good. Not everyone is using rust, and with this option
people who do will need to upgrade tooling, and people who don't care
don't need to do anything.

Thanks

Michal

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ