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: <20241219010054.pxcnejgkvy3g744k@jpoimboe>
Date: Wed, 18 Dec 2024 17:00:54 -0800
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Brendan Jackman <jackmanb@...gle.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Masahiro Yamada <masahiroy@...nel.org>,
	Nathan Chancellor <nathan@...nel.org>,
	Nicolas Schier <nicolas@...sle.eu>, linux-kernel@...r.kernel.org,
	linux-kbuild@...r.kernel.org
Subject: Re: [PATCH v2 0/2] objtool: Add option to fail build on vmlinux
 warnings

On Wed, Dec 18, 2024 at 04:06:56PM -0800, Andrew Morton wrote:
> On Wed, 18 Dec 2024 14:58:54 +0000 Brendan Jackman <jackmanb@...gle.com> wrote:
> 
> > This adds an option to objtool to exit with an error when it enounters
> > warnings.
> 
> Why is it optional?  Can we always fail the build so stuff gets fixed?

Eventually, yes.  But right now, I'm not so sure...

it will likely break a lot of robot builds, there are some obscure
randconfigs out there triggering some "interesting" edge cases, e.g.:

  - ftrace branch profiling which is fundamentally incompatible with
    uaccess STAC/CLAC rules

  - similar weirdnesses with UBSAN/KASAN/etc and other compiler
    features/plugins

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

-- 
Josh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ