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: <202507291506.1DF23781A2@keescook>
Date: Tue, 29 Jul 2025 15:12:20 -0700
From: Kees Cook <kees@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>
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 11:17:41PM +0200, Thomas Gleixner wrote:
> 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:

The change that I made that is triggering these warnings is:
381a38ea53d2 ("init.h: Disable sanitizer coverage for __init and __head")

The __init vs inline warnings I saw as I was working on this and had
been tackling them. Arnd found a couple more recently, too:
https://lore.kernel.org/all/f8bcf5ce-8b8b-4555-a210-14e1974eac92@app.fastmail.com/

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

Now this 'efi' issue got noticed too, and it seemed to be a preexisting
problem with GCC 12:
https://lore.kernel.org/all/202507272255.50254C0C@keescook/

There were the same linking problems even before 381a38ea53d2.

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

-- 
Kees Cook

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ