From: Nathan Chancellor <nathan@kernel.org>
To: Kees Cook <kees@kernel.org>
Cc: "Gustavo A . R . Silva" <gustavoars@kernel.org>,
"Nicolas Schier" <nicolas.schier@linux.dev>,
"Masahiro Yamada" <masahiroy@kernel.org>,
"Miguel Ojeda" <ojeda@kernel.org>,
linux-kbuild@vger.kernel.org,
"Thomas Weißschuh" <thomas.weissschuh@linutronix.de>,
"Tamir Duberstein" <tamird@gmail.com>,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH v2] kbuild: Enable GCC diagnostic context for value-tracking warnings
Date: Fri, 21 Nov 2025 15:21:50 -0700 [thread overview]
Message-ID: <20251121222150.GB1674270@ax162> (raw)
In-Reply-To: <20251121184342.it.626-kees@kernel.org>
On Fri, Nov 21, 2025 at 10:43:48AM -0800, Kees Cook wrote:
> Enable GCC 16's coming "-fdiagnostics-show-context=N" 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, so we can track the rationale for the warning,
> letting us more quickly identify actual issues vs what have looked in
> the past like false positives. Fixes based on this work have already
> been landing, e.g.:
>
> 4a6f18f28627 ("net/mlx4_core: Avoid impossible mlx4_db_alloc() order value")
> 8a39f1c870e9 ("ovl: Check for NULL d_inode() in ovl_dentry_upper()")
> e5f7e4e0a445 ("drm/amdgpu/atom: Work around vbios NULL offset false positive")
>
> The context depth ("=N") 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.
>
> 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.
>
> While my testing has shown that "=1" reports enough for finding
> the origin of most bounds issues, I have used "=2" here just to be
> conservative. Build time measurements with this option off, =1, and =2
> are all with noise of each other, so there seems to be no harm in "turning
> it up". If we need to, we can make this value configurable in the future.
>
> Link: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6faa3cfe60ff9769d1bebfffdd2c7325217d7389 [1]
> Signed-off-by: Kees Cook <kees@kernel.org>
> ---
Thanks for the updates!
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> ---
> 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
>
next prev parent reply other threads:[~2025-11-21 22:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-21 18:43 [PATCH v2] kbuild: Enable GCC diagnostic context for value-tracking warnings Kees Cook
2025-11-21 19:01 ` Miguel Ojeda
2025-11-21 22:21 ` Nathan Chancellor [this message]
2025-11-26 7:49 ` Nicolas Schier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251121222150.GB1674270@ax162 \
--to=nathan@kernel.org \
--cc=gustavoars@kernel.org \
--cc=kees@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=nicolas.schier@linux.dev \
--cc=ojeda@kernel.org \
--cc=tamird@gmail.com \
--cc=thomas.weissschuh@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox