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

Message-ID: <874iuuk87e.ffs@tglx>
Date: Tue, 29 Jul 2025 23:17:41 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: 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, Kees Cook
 <kees@...nel.org>
Cc: Linus Torvalds <torvalds@...uxfoundation.org>
Subject: Re: [syzbot] upstream build error (23)

On Tue, Jul 29 2025 at 21:36, Thomas Gleixner wrote:
> On Tue, Jul 29 2025 at 06:43, syzbot wrote:
> and to keep the call for efi_init() as a symbol for the linker to
> resolve, which obviously fails.
>
> If I change the efi_enabled() stub to __always_inline, it's optimized
> out.

Kees has addressed similar problems in:

8245d47cfaba ("x86: Handle KCOV __init vs inline mismatches")
65c430906eff ("arm64: Handle KCOV __init vs inline mismatches")
c64d6be1a6f8 ("s390: Handle KCOV __init vs inline mismatches")
2424fe1cac4f ("arm: Handle KCOV __init vs inline mismatches")
d01daf9d95c9 ("mips: Handle KCOV __init vs inline mismatch")

> Disabling CONFIG_KCOV_INSTRUMENT_ALL makes it go away. So GCC confuses
> the optimizer when CONFIG_KCOV_INSTRUMENT_ALL is on.

Seems to be GCC 12 specific. GCC13 does not have that problem.

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

Thanks,

        tglx