linux-hardening - Re: [PATCH 0/2] string: strends() follow-ups

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: <CAHp75Vd962ASEjeiJpv_CcQALK=dayzSQRCN3b5Cyp5GmdjdVw@mail.gmail.com>
Date: Tue, 18 Nov 2025 12:31:50 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: Kees Cook <kees@...nel.org>, Andy Shevchenko <andy@...nel.org>, 
	Linus Walleij <linus.walleij@...aro.org>, linux-hardening@...r.kernel.org, 
	linux-kernel@...r.kernel.org, 
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>, Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: [PATCH 0/2] string: strends() follow-ups

On Tue, Nov 18, 2025 at 12:14 PM Bartosz Golaszewski <brgl@...ev.pl> wrote:
> On Tue, Nov 18, 2025 at 11:09 AM Andy Shevchenko
> <andy.shevchenko@...il.com> wrote:
> > On Tue, Nov 18, 2025 at 12:04 PM Bartosz Golaszewski <brgl@...ev.pl> wrote:

...

> > > A couple follow-up changes to the new strends() string helper. This
> > > needs to go through the GPIO tree as this is where the strends()
> > > currently is.

> > For the
> > strends() I proposed to get rid of strlen() calls by
> >
> >   char *p;
> >
> >   p = strrchr(str, suffix[0[);
> >   if (!p)
> >     return false;
> >
> >   return strcmp(p, suffix) == 0;
>
> IMO that's a bit less readable. Unless you benchmark it and show it's
> faster than the current version, I'd say: let's keep the current
> implementation.

For the static suffixes the second strlen() becomes a hardcoded value,
and I expect the benchmark will be closer to the variant I propose.
Otherwise it will be definitely faster as the strrchr() implies
partial strlen() and strcmp() is the same or even faster in my case as
here we don't do the additional calculations with the pointers. Do you
really need a benchmark for this?


-- 
With Best Regards,
Andy Shevchenko