linux-kernel - Re: [syzbot] upstream build error (23)

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: <871ppyj6um.ffs@tglx>
Date: Wed, 30 Jul 2025 12:44:33 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Kees Cook <kees@...nel.org>
Cc: syzbot <syzbot+5245cb609175fb6e8122@...kaller.appspotmail.com>,
 bp@...en8.de, dave.hansen@...ux.intel.com, hpa@...or.com,
 linux-kernel@...r.kernel.org, mingo@...hat.com,
 syzkaller-bugs@...glegroups.com, x86@...nel.org, Linus Torvalds
 <torvalds@...uxfoundation.org>, Arnd Bergmann <arnd@...db.de>
Subject: Re: [syzbot] upstream build error (23)

On Tue, Jul 29 2025 at 15:12, Kees Cook wrote:
> On Tue, Jul 29, 2025 at 11:17:41PM +0200, Thomas Gleixner wrote:
>> > The kernel is full of such inline (not __always_inline) stub
>> > conditionals which evaluate to a constant....
>> 
>> And chasing all those stubs and convert them to __always_inline seems to
>> be a whack-a-mole game.
>> 
>> Can we just stop pretending that GCC12 is KCOV capable?
>
> That's fine by me, but I do think something weirder is happening here.
> Those efi linkages should be entirely DCE'ed?

Of course.

Though it un-inlines the stub function and slaps the sanitizer call into
it, which seems to prevent DCE to drop it:

	.type   efi_enabled.constprop.0, @function
efi_enabled.constprop.0:
.LASANPC6082:
.LFB6082:
        .file 5 "/home/tglx/work/kernel/linus/linux/include/linux/efi.h"
        .loc 5 891 20 is_stmt 1 view -0
        .cfi_startproc
.LVL13:
        .loc 5 893 2 view .LVU43
        .loc 5 893 9 is_stmt 0 view .LVU44
        call    __sanitizer_cov_trace_pc
.LVL14:
	.loc 5 894 1 view .LVU45
	xorl    %eax, %eax
	jmp     __x86_return_thunk
	.cfi_endproc

We had similar issues with function tracing in the past where different
GCC versions decided un-inlining at random places, so we ended up adding
notrace to the inline define.

Adding __no_sanitize_coverage as well is curing it for good.

Thanks,

        tglx
---
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 2b77d12e07b2..46f7722039c3 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -233,7 +233,7 @@ struct ftrace_likely_data {
  * of extern inline functions at link time.
  * A lot of inline functions can cause havoc with function tracing.
  */
-#define inline inline __gnu_inline __inline_maybe_unused notrace
+#define inline inline __gnu_inline __inline_maybe_unused notrace __no_sanitize_coverage
 
 /*
  * gcc provides both __inline__ and __inline as alternate spellings of