linux-kernel - Re: [PATCH v5 14/16] modules: Support extended MODVERSIONS info

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: <CABCJKudyC_EzRTtkJSSQqQhLdUk_9tYBtoq62tjmghFyi8omWg@mail.gmail.com>
Date: Thu, 26 Sep 2024 11:36:51 -0700
From: Sami Tolvanen <samitolvanen@...gle.com>
To: Christophe Leroy <christophe.leroy@...roup.eu>
Cc: Matthew Maurer <mmaurer@...gle.com>, masahiroy@...nel.org, ndesaulniers@...gle.com, 
	ojeda@...nel.org, gary@...yguo.net, mcgrof@...nel.org, 
	Michael Ellerman <mpe@...erman.id.au>, Alex Gaynor <alex.gaynor@...il.com>, 
	Benjamin Gray <bgray@...ux.ibm.com>, Naveen N Rao <naveen@...nel.org>, rust-for-linux@...r.kernel.org, 
	linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org, neal@...pa.dev, 
	marcan@...can.st, j@...nau.net, asahi@...ts.linux.dev, 
	linux-modules@...r.kernel.org, Nicholas Piggin <npiggin@...il.com>, 
	Madhavan Srinivasan <maddy@...ux.ibm.com>, Petr Pavlu <petr.pavlu@...e.com>, 
	Daniel Gomez <da.gomez@...sung.com>, Boqun Feng <boqun.feng@...il.com>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Benno Lossin <benno.lossin@...ton.me>, Andreas Hindborg <a.hindborg@...nel.org>, 
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH v5 14/16] modules: Support extended MODVERSIONS info

On Thu, Sep 26, 2024 at 5:22 AM Christophe Leroy
<christophe.leroy@...roup.eu> wrote:
>
>
>
> Le 26/09/2024 à 01:38, Matthew Maurer a écrit :
> > Adds a new format for MODVERSIONS which stores each field in a separate
> > ELF section. This initially adds support for variable length names, but
> > could later be used to add additional fields to MODVERSIONS in a
> > backwards compatible way if needed. Any new fields will be ignored by
> > old user tooling, unlike the current format where user tooling cannot
> > tolerate adjustments to the format (for example making the name field
> > longer).
> >
> > Since PPC munges its version records to strip leading dots, we reproduce
> > the munging for the new format. Other architectures do not appear to
> > have architecture-specific usage of this information.
> >
> > Signed-off-by: Matthew Maurer <mmaurer@...gle.com>
> > ---
> >   arch/powerpc/kernel/module_64.c | 23 ++++++++-
> >   kernel/module/internal.h        | 11 ++++
> >   kernel/module/main.c            | 92 ++++++++++++++++++++++++++++++---
> >   kernel/module/version.c         | 45 ++++++++++++++++
> >   4 files changed, 161 insertions(+), 10 deletions(-)
> >
> > diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
> > index e9bab599d0c2..4e7b156dd8b2 100644
> > --- a/arch/powerpc/kernel/module_64.c
> > +++ b/arch/powerpc/kernel/module_64.c
> > @@ -355,6 +355,23 @@ static void dedotify_versions(struct modversion_info *vers,
> >               }
> >   }
> >
> > +static void dedotify_ext_version_names(char *str_seq, unsigned long size)
> > +{
> > +     unsigned long out = 0;
> > +     unsigned long in;
> > +     char last = '\0';
> > +
> > +     for (in = 0; in < size; in++) {
> > +             /* Skip one leading dot */
> > +             if (last == '\0' && str_seq[in] == '.')
> > +                     in++;
> > +             last = str_seq[in];
> > +             str_seq[out++] = last;
> > +     }
>
> Why do you need a loop here ?
>
> Can't you just do something like:
>
>         if (str_seq[0] == '.')
>                 memmove(str_seq, str_seq + 1, size);

I initially had the same thought, but it's because this is is a
sequence of multiple null-terminated strings, and we need to dedotify
all of them, not just the first one. Here's an example:

https://godbolt.org/z/avMGnd48M

> > +     /* Zero the trailing portion of the names table for robustness */
> > +     memset(&str_seq[out], 0, size - out);
>
> This seems unneeded.

Strictly speaking it shouldn't be needed, but I think it's still good
hygiene to not leave another null-terminated fragment at the end.

Sami