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] [thread-next>] [day] [month] [year] [list]

Message-ID: <202508261911.ECB628656@keescook>
Date: Tue, 26 Aug 2025 19:13:03 -0700
From: Kees Cook <kees@...nel.org>
To: Yury Norov <yury.norov@...il.com>
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 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
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).

> 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.

-- 
Kees Cook