linux-kernel - Re: [PATCH v7 1/3] 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] [day] [month] [year] [list]

Message-ID: <878qu6dugh.fsf@mpe.ellerman.id.au>
Date: Wed, 30 Oct 2024 16:35:10 +1100
From: Michael Ellerman <mpe@...erman.id.au>
To: Matthew Maurer <mmaurer@...gle.com>
Cc: Nicholas Piggin <npiggin@...il.com>, Christophe Leroy
 <christophe.leroy@...roup.eu>, Naveen N Rao <naveen@...nel.org>, Madhavan
 Srinivasan <maddy@...ux.ibm.com>, Luis Chamberlain <mcgrof@...nel.org>,
 Petr Pavlu <petr.pavlu@...e.com>, Sami Tolvanen <samitolvanen@...gle.com>,
 Daniel Gomez <da.gomez@...sung.com>, Masahiro Yamada
 <masahiroy@...nel.org>, Nathan Chancellor <nathan@...nel.org>, Nicolas
 Schier <nicolas@...sle.eu>, Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor
 <alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>, Gary Guo
 <gary@...yguo.net>, 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, linux-kernel@...r.kernel.org,
 linux-modules@...r.kernel.org, linux-kbuild@...r.kernel.org,
 rust-for-linux@...r.kernel.org
Subject: Re: [PATCH v7 1/3] modules: Support extended MODVERSIONS info

Matthew Maurer <mmaurer@...gle.com> writes:
>> Sorry I realise it's version 7, but although the above looks correct it's
>> kind of dense.
>>
>> I think the below would also work and is (I think) easier to follow, and
>> is more obviously similar to the existing code. I'm sure your version is
>> faster, but I don't think it's that performance critical.
>>
>> static void dedotify_ext_version_names(char *str_seq, unsigned long size)
>> {
>>         char *end = str_seq + size;
>>         char *p = str_seq;
>>
>>         while (p < end) {
>>                 if (*p == '.')
>>                         memmove(p, p + 1, end - p - 1);
>>
>>                 p += strlen(p) + 1;
>>         }
>> }
>>
>> The tail of str_seq will be filled with nulls as long as the last string
>> was null terminated.
>
> As you alluded to, what you're providing is potentially O(n^2) in the
> number of symbols a module depends on - the existing code is O(n).
> If leading dots on names are rare, this is probably fine. If they're
> common, this will potentially make loading modules with a large number
> of imported symbols actually take a measurable amount of additional
> time.

It should only be a single symbol these days, .TOC., for both big and
little endian builds.

But maybe someone out there is still building their kernel ELFv1, in
which case every function will begin with '.'.

I still don't think it will be measurable, but n^2 is asking for
trouble.

So forget it, just use your version, you've already written it anyway.
Sorry for the noise.

cheers