linux-hardening - Re: [PATCH] arc: Fix __fls() const-foldability via __builtin

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: <aK5-T0C6MA5hbdRr@yury>
Date: Tue, 26 Aug 2025 23:41:03 -0400
From: Yury Norov <yury.norov@...il.com>
To: Kees Cook <kees@...nel.org>
Cc: Rasmus Villemoes <ravi@...vas.dk>, kernel test robot <lkp@...el.com>,
	Vineet Gupta <vgupta@...nel.org>,
	linux-snps-arc@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-hardening@...r.kernel.org
Subject: Re: [PATCH] arc: Fix __fls() const-foldability via __builtin_clzl()

On Tue, Aug 26, 2025 at 07:13:03PM -0700, Kees Cook wrote:
> On Tue, Aug 26, 2025 at 09:24:04PM -0400, Yury Norov wrote:
> > On Tue, Aug 26, 2025 at 09:56:06AM -0700, Kees Cook wrote:
> > > On Tue, Aug 26, 2025 at 03:08:59PM +0200, Rasmus Villemoes wrote:
> > > > If __builtin_arc_fls() simply doesn't qualify for attr_const for
> > > > $reason, I think it would be good to have that documented in the commit
> > > > msg. If it does, I think a gcc ticket and link to that would be in order.
> > > 
> > > I already sent the patch to fix it. :)
> > > 
> > > https://gcc.gnu.org/pipermail/gcc-patches/2025-August/693273.html
> > 
> > I'm OK taking the patch if it fixes real problem for you, but it looks
> > more like a GCC problem, right? Is Clang also affected?
> 
> Without it, KUnit testing of ffs/fls fails on arc. Clang is not

That's a solid point. Can you please notice it in changelog too?

> affected. Even with the GCC fix landed, all older GCCs with still fail,
> and since it provides a improved code generation for arc, it seems worth
> it (compile-time-calculable values will be emitted instead of always
> running the arc instructions).

Yep. This is what I meant. Once the fix is landed, we will not need this
code. When the minimal supported GCC version will become greater than
one that has the fix applied, it will be much easier to spot this hack
and drop it, if we mention that explicitly.

Something like that:

    #if IS_ENABLED(CONFIG_CC_IS_GCC) && CONFIG_GCC_VERSION < XXX
        if ( __builtin_constant_p(x))
                return x ? BITS_PER_LONG - 1 - __builtin_clzl(x) : 0;
    #endif

> > If, say, Clang is not affected, and you expect that newer GCC versions
> > will not be affected too, let's protect the new code with a proper
> > ifdefery, so that it will be easier to drop the workaround later?
> 
> I think the codegen benefit is worth it as I have it.

That's I'm surely agree.