linux-kernel - Re: [PATCH v2 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241219221913.GA1259354@ax162>
Date: Thu, 19 Dec 2024 15:19:13 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Josh Poimboeuf <jpoimboe@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	Brendan Jackman <jackmanb@...gle.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Masahiro Yamada <masahiroy@...nel.org>,
	Nicolas Schier <nicolas@...sle.eu>, linux-kernel@...r.kernel.org,
	linux-kbuild@...r.kernel.org, llvm@...ts.linux.dev
Subject: Re: [PATCH v2 0/2] objtool: Add option to fail build on vmlinux
 warnings

Hi Josh,

On Wed, Dec 18, 2024 at 05:00:54PM -0800, Josh Poimboeuf wrote:
...
>   - obscure toolchain bugs in certain compiler versions which do weird
>     things with control flow.  some of these bugs break the kernel, some
>     don't.
> 
> Problem is, it usually falls on the objtool maintainers to figure out
> the root of the problem and the resolution, neither of which is
> necessarily straightforward, especially the latter.  There's only two of
> us maintainers at the moment, with limited bandwidth.
> 
> So yes, it *should* always fail the build.  But unless we get more
> maintainer bandwidth, I don't think we're ready for that.
> 
> We might end up being able to make CONFIG_OBJTOOL_WERROR=y the default,
> and then just require broken features to depend on
> CONFIG_OBJTOOL_WERROR=n.  And then print a big fat warning message at
> build and/or runtime in the case of warnings.
> 
> We also might need to add some features, like a way to mark certain
> compiler versions as bad, or a way to silence objtool warnings for
> certain known harmless cases, or improve the specificity and usefulness
> of certain vague warnings.
> 
> But as a first step I'll planning on just throwing these patches on a
> robot-monitored branch with CONFIG_OBJTOOL_WERROR=y over the holidays to
> see how bad the damage is.

For the record, I plan to monitor these reports for LLVM and try to
investigate and triage all other known objtool warnings for LLVM after
the holidays to try and prepare for this. I felt blind sided by the
compiler -Werror change so I'd rather not go through that again :) one
reason I would like to be objtool clean is to catch changed compiler
behavior quicker, as I tend to notice it is easier to get problems
addressed when the problem is reported as close as possible to the
original change.

I do agree with you that figuring our the root problem and resolution to
some of these warnings is not always the easiest, especially when they
are on the toolchain side, so I have often kicked the can down the road.
I know there is some documentation in objtool.txt around various
warnings, is that pretty up to date/accurate? Are there any other
resources I could look at to help with this work? I know Arnd just
recently fixed a set [1] that I saw in our builds as well due to a bare
unreachable(), which I think tend to hurt Clang more than GCC but maybe
I am imagining things there.

Some objtool reports get sent to only llvm@...ts.linux.dev when clang is
involved (due to a historical filter IIRC, I cannot find the original
request), so you may want to glance at [2] to see if anything new pops
up.

[1]: https://git.kernel.org/netdev/net/c/cff865c700711ecc3824b2dfe181637f3ed23c80
[2]: https://lore.kernel.org/llvm/?q=objtool+f:lkp@intel.com

Cheers,
Nathan