[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20251121222150.GB1674270@ax162>
Date: Fri, 21 Nov 2025 15:21:50 -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 v2] kbuild: Enable GCC diagnostic context for
value-tracking warnings
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@...nel.org>
> ---
Thanks for the updates!
Reviewed-by: Nathan Chancellor <nathan@...nel.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
>
Powered by blists - more mailing lists