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 for Android: free password hash cracker in your pocket

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

Message-ID: <20251120064923.GA3320872@ax162>
Date: Wed, 19 Nov 2025 23:49:23 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Kees Cook <kees@...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 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?

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

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

> Signed-off-by: Kees Cook <kees@...nel.org>
> ---

Reviewed-by: Nathan Chancellor <nathan@...nel.org>

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

> ---
>  Makefile | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Makefile b/Makefile
> index d14824792227..d97452441cd0 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -940,6 +940,9 @@ KBUILD_CFLAGS += $(call cc-option,-fzero-init-padding-bits=all)
>  # for the randomize_kstack_offset feature. Disable it for all compilers.
>  KBUILD_CFLAGS	+= $(call cc-option, -fno-stack-clash-protection)
>  
> +# Get details on warnings generated due to GCC value tracking.
> +KBUILD_CFLAGS	+= $(call cc-option, -fdiagnostics-show-context=2)
> +
>  # Clear used registers at func exit (to reduce data lifetime and ROP gadgets).
>  ifdef CONFIG_ZERO_CALL_USED_REGS
>  KBUILD_CFLAGS	+= -fzero-call-used-regs=used-gpr
> -- 
> 2.34.1
>