linux-kernel - Re: [PATCH v3 0/2] objtool: Add option to fail build on vmlinux warnings

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: <20250130183042.GB3394637@ax162>
Date: Thu, 30 Jan 2025 11:30:42 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Brendan Jackman <jackmanb@...gle.com>
Cc: Josh Poimboeuf <jpoimboe@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Masahiro Yamada <masahiroy@...nel.org>,
	Nicolas Schier <nicolas@...sle.eu>, linux-kernel@...r.kernel.org,
	linux-kbuild@...r.kernel.org
Subject: Re: [PATCH v3 0/2] objtool: Add option to fail build on vmlinux
 warnings

On Thu, Jan 30, 2025 at 04:55:39PM +0100, Brendan Jackman wrote:
> On Tue, 14 Jan 2025 at 01:14, Josh Poimboeuf <jpoimboe@...nel.org> wrote:
> > Thanks!  I'm putting it through bot testing now.
> 
> Hey Josh, how has it been going - could we merge the feature?
> 
> (Or, has it already been merged in some tree that doesn't go into linux-next?)

It looks like it is in Josh's tree but that tree does not flow into
-next; IIRC, they have to be merged into -tip to show up there.

https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git/log/?h=objtool/core

For the record, this will be disruptive for clang users because a number
of warnings have crept up in recent releases and this option will get
enabled for allmodconfig. I have started going through them all but I am
working at an unfortunate intersection between compiler/optimization
internals, other flags such as sanitizers, and reconstructing control
flow. Most of them are "falls through to the next function" or
"unexpected end of section" warnings, which generally mean some
undefined behavior has been encountered and clang has given up code
generation. Figuring out what changed on the LLVM side requires a bisect
then reporting it (if it is a legitimate compiler problem) requires a
source file reduction. I did explore turning unreachable into a trap to
fix several of those but I think that will need further objtool changes
to cure the warnings that were reported:

https://lore.kernel.org/all/?q=llvm-trap-unreachable

I think Josh already mentioned it but exposing -Werror for objtool is a
big committment. Any time the build breaks because of it (even due to
external factors such as a compiler upgrade), there will be a need for
triage and just saying "turn off CONFIG_OBJTOOL_WERROR" cannot always be
the solution otherwise it loses its power. While it is nice leverage to
keep things clean (and I feel like it has generally worked well for
compilers with CONFIG_WERROR), it is disruptive and requires real labor
to upkeep, which should be from the authors who introduce the warnings
but they might need guidance or advice. I am regularly helping people
with figuring out issues from the LLVM toolchain becuase they get a
report that they have broken something but they do not use LLVM so they
are unsure what to do or what it means. I am not saying this is all a
bad idea but I want to make sure that this committment has been
considered.

If exposing this to the world feels too premature, maybe the flag could
be added then have a make variable like OBJTOOL_FLAGS to allow a
developer to pass it through if they wish?

Cheers,
Nathan