linux-kernel - Re: Build breakage caused by the use of UDB

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: <20251217133431.GF3708021@noisy.programming.kicks-ass.net>
Date: Wed, 17 Dec 2025 14:34:31 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Jean Delvare <jdelvare@...e.de>
Cc: LKML <linux-kernel@...r.kernel.org>, ubizjak@...il.com,
	Josh Poimboeuf <jpoimboe@...hat.com>, ardb@...nel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>, x86@...nel.org
Subject: Re: Build breakage caused by the use of UDB

On Wed, Dec 17, 2025 at 02:02:04PM +0100, Peter Zijlstra wrote:
> On Wed, Dec 17, 2025 at 01:47:13PM +0100, Peter Zijlstra wrote:
> > On Wed, Dec 17, 2025 at 01:35:36PM +0100, Peter Zijlstra wrote:
> > > On Wed, Dec 17, 2025 at 12:44:23PM +0100, Jean Delvare wrote:
> > > > Hi Peter,
> > > > 
> > > > Kernel v6.18.1 doesn't build on x86_64 for me. The build failure is:
> > > > 
> > > > make[1]: Entering directory '/home/khali/src/linux-6.18/drivers/net/wireless/realtek/rtlwifi/rtl8192c'
> > > >   CC [M]  main.o
> > > >   CC [M]  dm_common.o
> > > >   CC [M]  fw_common.o
> > > >   CC [M]  phy_common.o
> > > >   CHECK   main.c
> > > > fw_common.c: Assembler messages:
> > > > fw_common.c:416: Error: unknown pseudo-op: `.byte0x0f'
> > > > fw_common.c:391: Error: unknown pseudo-op: `.byte0x0f'
> > > > make[3]: *** [/home/khali/src/linux-6.18/scripts/Makefile.build:287: fw_common.o] Error 1
> > > > make[3]: *** Waiting for unfinished jobs....
> > > >   CHECK   dm_common.c
> > > > phy_common.c: Assembler messages:
> > > > phy_common.c:58: Error: unknown pseudo-op: `.byte0x0f'
> > > > phy_common.c:67: Error: unknown pseudo-op: `.byte0x0f'
> > > > ../wifi.h:3033: Error: unknown pseudo-op: `.byte0x0f'
> > > > ../wifi.h:3033: Error: unknown pseudo-op: `.byte0x0f'
> > > > phy_common.c:807: Error: unknown pseudo-op: `.byte0x0f'
> > > > phy_common.c:714: Error: unknown pseudo-op: `.byte0x0f'
> > > > make[3]: *** [/home/khali/src/linux-6.18/scripts/Makefile.build:287: phy_common.o] Error 1
> > > > make[2]: *** [/home/khali/src/linux-6.18/Makefile:2010: .] Error 2
> > > > make[1]: *** [/home/khali/src/linux-6.18/Makefile:248: __sub-make] Error 2
> > > > make[1]: Leaving directory '/home/khali/src/linux-6.18/drivers/net/wireless/realtek/rtlwifi/rtl8192c'
> > > > make: *** [Makefile:248: __sub-make] Error 2
> > > > 
> > > > I bisected it down to:
> > > > 
> > > > commit 85a2d4a890dce3cfc9c14aa91afc3dd7af8e3bf5
> > > > Author: Peter Zijlstra
> > > > Date:   Mon Sep 1 12:49:58 2025 +0200
> > > > 
> > > >     x86,ibt: Use UDB instead of 0xEA
> > > > 
> > > > Reverting this commit allows me to build v6.18.1.
> > > > 
> > > > I must confess this is all way beyond me and I have no idea how this
> > > > change can cause such a build failure, but it does. If it matters, my
> > > > compiler is gcc 8.2.1.
> > > 
> > > Well, that is somewhat unexpected. None of the build robots fingered
> > > this. Is there a particular .config I should try?
> > > 
> > > I don't seem to have 8.2.1 at hand, but I'll try with 8.3.0.
> > 
> > I had to (obviously) enable the RTL8192 bits, but then, yes. gcc-8 fails
> > to build this while gcc-10 doesn't seem to have any problems (for some
> > reason my random dev machine of the day doesn't seem to have gcc-9).
> > 
> > Let me prod at this for a bit. But also, is there a good reason you're
> > using this stone-age compiler? :-) And yes, its our minimum supported,
> > so I suppose I should go fix, but other than build testing, you really
> > shoulnd't be using it.
> 
> Yeah _ASM_BYTES(0x0f, 0x0b) doesn't seem to work right with gcc-8. It
> results in: .byte0x0f, 0x0b ; instead of the expected: .byte 0x0f, 0x0b ;
> 
> What's worse, it only sometimes does this:
> 
> $ grep ".byte[ ]*0x0f" defconfig-build/drivers/net/wireless/realtek/rtlwifi/base.s
>         1:       .byte0x0f,0x0b ;
>         1:       .byte 0x0f,0x0b ;
> 
> W.T.F. and all that.

The below seems to 'cure' things, but I'm not sure this is the best
option. Expanded Cc for more suggestions.

---
diff --git a/arch/x86/include/asm/asm.h b/arch/x86/include/asm/asm.h
index 0e8c611bc9e2..8f6c834a6164 100644
--- a/arch/x86/include/asm/asm.h
+++ b/arch/x86/include/asm/asm.h
@@ -9,15 +9,16 @@
 # define __ASM_FORM_RAW(x, ...)		x,## __VA_ARGS__
 # define __ASM_FORM_COMMA(x, ...)	x,## __VA_ARGS__,
 # define __ASM_REGPFX			%
+# define _ASM_BYTES(...)		.byte __VA_ARGS__ ;
 #else
 #include <linux/stringify.h>
 # define __ASM_FORM(x, ...)		" " __stringify(x,##__VA_ARGS__) " "
 # define __ASM_FORM_RAW(x, ...)		    __stringify(x,##__VA_ARGS__)
 # define __ASM_FORM_COMMA(x, ...)	" " __stringify(x,##__VA_ARGS__) ","
 # define __ASM_REGPFX			%%
-#endif
+# define _ASM_BYTES(...)	        " .byte " __stringify(__VA_ARGS__) " ;"
 
-#define _ASM_BYTES(x, ...)	__ASM_FORM(.byte x,##__VA_ARGS__ ;)
+#endif
 
 #ifndef __x86_64__
 /* 32 bit */