linux-kernel - Re: [patch V2 2/6] kbuild: Disable asm goto on clang

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: <87ikhi9lhg.ffs@tglx>
Date: Tue, 16 Sep 2025 22:43:39 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Nathan Chancellor <nathan@...nel.org>
Cc: LKML <linux-kernel@...r.kernel.org>, Linus Torvalds
 <torvalds@...ux-foundation.org>, Peter Zijlstra <peterz@...radead.org>,
 kernel test robot <lkp@...el.com>, Russell King <linux@...linux.org.uk>,
 linux-arm-kernel@...ts.infradead.org, Christophe Leroy
 <christophe.leroy@...roup.eu>, Darren Hart <dvhart@...radead.org>,
 Davidlohr Bueso <dave@...olabs.net>, André Almeida
 <andrealmeid@...lia.com>, x86@...nel.org, Alexander Viro
 <viro@...iv.linux.org.uk>, Christian Brauner <brauner@...nel.org>, Jan
 Kara <jack@...e.cz>, linux-fsdevel@...r.kernel.org
Subject: Re: [patch V2 2/6] kbuild: Disable asm goto on clang < 17

Nathan!

On Tue, Sep 16 2025 at 11:44, Nathan Chancellor wrote:
> First of all, sorry you got bit by this issue.

The real annoying thing was that I could not makes sense of the error
messages and when I started shuffling code around for analysis it got
worse by failing reliably even with one instance or it exposed random
other incomprehensible errors which did not help analysis either.

Sh*t happens :)

> On Tue, Sep 16, 2025 at 06:33:11PM +0200, Thomas Gleixner wrote:
>> clang < 17 fails to use scope local labels with asm goto:
>> 
>>      {
>>      	__label__ local_lbl;
>> 	...
>> 	unsafe_get_user(uval, uaddr, local_lbl);
>> 	...
>> 	return 0;
>> 	local_lbl:
>> 		return -EFAULT;
>>      }
>> 
>> when two such scopes exist in the same function:
>> 
>>   error: cannot jump from this asm goto statement to one of its possible targets
>
> For the record, this is not specific to local labels, unique function
> labels could trigger this error as well, as demonstrated by Nick's test
> case:
>
> https://github.com/ClangBuiltLinux/linux/issues/1886#issuecomment-1636342477

Ah! I somehow failed to find this one.

I was actually trying to create a simple reproducer for using in the
depends on $(success,echo...) magic and could not manage.

The test case in the issue tracker is really helpful as it can be
condensed into the obfuscated C-code contest format required for
'depends on' checks. So we don't need the version number hack for
detecting it. That's definitely preferred as it catches potential
misbehaviour of later versions and of other compilers as well.

I'll send out a revised patch to that effect later.

>> That prevents using local labels for a cleanup based user access mechanism.
>
> Indeed. This has only popped up a couple of times in the past couple of
> years and each time it has been easy enough to work around by shuffling
> the use of asm goto but as cleanup gets used in more places, this is
> likely to cause problems.

Yes. I noticed that moving the label around or rearraning code slightly
makes it go away or even worse, but that's not a real solution :)

>> As there is no way to provide a simple test case for the 'depends on' test
>> in Kconfig, mark ASM goto broken on clang versions < 17 to get this road
>> block out of the way.
>
> That being said, the commit title and message always references asm goto
> in the general sense but this change only affects asm goto with
> outputs.

Right, that's misleading.

> Is it sufficient to resolve the issues you were seeing? As far as I
> understand it, the general issue can affect asm goto with or without
> outputs but I assume x86 won't have any issues because the label is not
> used in __get_user_asm when asm goto with outputs is not supported?

I haven't seen a problem with that yet. So yes, as things stand that
seems to be a ASM_GOTO_OUTPUT issue.

>> +config CLANG_ASM_GOTO_OUTPUT_BROKEN
>> +	bool
>> +	depends on CC_IS_CLANG
>> +	default y if CLANG_VERSION < 170000
>
> Assuming this change sticks, please consider including links to the
> original bug report and the fix in LLVM:
>
>   https://github.com/ClangBuiltLinux/linux/issues/1886
>   https://github.com/llvm/llvm-project/commit/f023f5cdb2e6c19026f04a15b5a935c041835d14

Sure! That's indeed useful.

Thanks,

        tglx