linux-kernel - Re: [PATCH] kbuild: Enable GCC diagnostic context for value-tracking 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: <202511211027.864DFA90@keescook>
Date: Fri, 21 Nov 2025 10:30:48 -0800
From: Kees Cook <kees@...nel.org>
To: Nathan Chancellor <nathan@...nel.org>
Cc: "Gustavo A . R . Silva" <gustavoars@...nel.org>,
	Nicolas Schier <nicolas.schier@...ux.dev>,
	Masahiro Yamada <masahiroy@...nel.org>,
	Miguel Ojeda <ojeda@...nel.org>, linux-kbuild@...r.kernel.org,
	Thomas Weißschuh <thomas.weissschuh@...utronix.de>,
	Tamir Duberstein <tamird@...il.com>, linux-kernel@...r.kernel.org,
	linux-hardening@...r.kernel.org
Subject: Re: [PATCH] kbuild: Enable GCC diagnostic context for value-tracking
 warnings

On Wed, Nov 19, 2025 at 11:49:23PM -0700, Nathan Chancellor wrote:
> On Wed, Nov 19, 2025 at 02:44:31PM -0800, Kees Cook wrote:
> > Enable GCC 16's coming "-fdiagnostics-show-context=2" option[1] to
> > provide enhanced diagnostic information for value-tracking warnings, which
> > displays the control flow chain leading to the diagnostic. This covers our
> > existing use of -Wrestrict and -Wstringop-overread, and gets us closer to
> > enabling -Warray-bounds, -Wstringop-overflow, and -Wstringop-truncation.
> > 
> > The context depth of 2 provides the immediate decision path that led to
> > the problematic code location, showing conditional checks and branch
> > decisions that caused the warning. This will help us understand why
> > GCC's value-tracking analysis triggered the warning and makes it easier
> > to determine whether warnings are legitimate issues or false positives.
> 
> Would we ever want a depth more than 2? In other words, should this be
> customizable in case there is a warning that needs more context?

Honestly, I'm not sure yet. I think if we find it to be true, we can
add it then. So far, everything I've found works with =1, but I went
with =2 just to be conservative. (And I did build time comparisons --
there is no measurable difference between off, 1, or 2.)

> > For example, an array bounds warning will now show the conditional
> > statements (like "if (i >= 4)") that established the out-of-bounds access
> > range, directly connecting the control flow to the warning location.
> > This is particularly valuable when GCC's interprocedural analysis can
> > generate warnings that are difficult to understand without seeing the
> > inferred control flow.
> 
> Not that it is that different from what you describe here but having an
> actual example of the insight that this gives using a problematic case
> from the past (such as one that resulted in these various warnings
> getting disabled) might be useful for future travellers.

Yeah, I can list some of the prior fixes.

> > Link: https://github.com/gcc-mirror/gcc/commit/6faa3cfe60ff9769d1bebfffdd2c7325217d7389 [1]
> 
> I have a small preference for using links that the project controls,
> i.e.
> 
>   https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6faa3cfe60ff9769d1bebfffdd2c7325217d7389
> 
> but I am guessing that mirror is not going anywhere and we have the hash
> regardless so consider it a nit.

I regularly have gcc.gnu.org time out for me, so I've been using github
for trees and references, but I can change this.

> 
> > Signed-off-by: Kees Cook <kees@...nel.org>
> > ---
> 
> Reviewed-by: Nathan Chancellor <nathan@...nel.org>

Thanks!

> Should we take this via Kbuild or do you want to take it via the
> hardening tree?

I figured I'd take it via the hardening tree, but I have no strong
rationale for that. ;)

-Kees

-- 
Kees Cook