Re: [PATCH v2] kstack_erase: suppress -grecord-gcc-switches for external module builds

Re: [PATCH v2] kstack_erase: suppress -grecord-gcc-switches for external module builds

[Nicolas Schier]

[ Please reply interleaved,
  cp.  Documentation/process/submitting-patches.rst ]

On Fri, Aug 14, 2026 at 08:27:58AM +0000, Jaihind Yadav wrote:
> Hi Kees,
> 
>   That's a fair point.
> 
>   In my testing, the issue was observed specifically with the STACKLEAK
>   plugin path being recorded in DWARF producer strings for KBUILD_EXTMOD
>   builds via:
> 
>     -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
> 
>   The motivation for this patch was to address that specific issue with
>   the smallest possible change.
> 
>   I agree the same behavior may apply to other GCC plugins when their
>   -fplugin arguments contain build-specific absolute paths. A more general
>   solution may make sense, but I wasn't sure whether disabling recorded
>   GCC switches more broadly would be desirable from a debugging
>   information perspective.

[...]
> On Thu, Aug 13, 2026 at 01:59:49PM +0530, Jaihind Yadav wrote:
> > With CONFIG_GCC_PLUGIN_STACKLEAK=y, kstack erase adds:
> >
> >   -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
> >
> > For KBUILD_EXTMOD builds, recording gcc switches can embed this 
> > host/build specific plugin path into module DWARF producer strings, 
> > which trips QA checks looking for absolute path leakage.
> 
> Isn't this a problem for all Linux gcc plugins, though?
> 
> -Kees
> 
> >
> > Disable gcc switch recording only for external modules by adding 
> > -gno-record-gcc-switches to kstack-erase-cflags when KBUILD_EXTMOD is set.
> >
> > This keeps stackleak plugin instrumentation enabled while avoiding 
> > leakage of host-specific paths in external module debug metadata.
> >
> > Suggested-by: Nathan Chancellor <nathan@kernel.org>
> > Link: https://lore.kernel.org/all/20260803181217.GB1067866@ax162/
> > Signed-off-by: Jaihind Yadav <jaihindy@qti.qualcomm.com>
> > ---
> >  scripts/Makefile.kstack_erase | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/scripts/Makefile.kstack_erase b/scripts/Makefile.kstack_erase
> > index ee7e4ef7b892..6f31a3915d24 100644
> > --- a/scripts/Makefile.kstack_erase
> > +++ b/scripts/Makefile.kstack_erase
> > @@ -5,6 +5,7 @@ kstack-erase-cflags-y += -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugi
> >  kstack-erase-cflags-y += -fplugin-arg-stackleak_plugin-track-min-size=$(CONFIG_KSTACK_ERASE_TRACK_MIN_SIZE)
> >  kstack-erase-cflags-y += -fplugin-arg-stackleak_plugin-arch=$(SRCARCH)
> >  kstack-erase-cflags-$(CONFIG_GCC_PLUGIN_STACKLEAK_VERBOSE) += -fplugin-arg-stackleak_plugin-verbose
> > +kstack-erase-cflags-$(if $(KBUILD_EXTMOD),y) += -gno-record-gcc-switches

As -gno-record-gcc-switches is not specific to kstack-erase, I am not
convinced that CONFIG_GCC_PLUGIN_STACKLEAK is a good switch for it.
Might it be that someone has CONFIG_GCC_PLUGIN_STACKLEAK enabled but
wants (some other) gcc switches to be recorded?


If there is a need for external kmods to to have 

  make modules KCFLAGS=-gno-record-gcc-switches

automated in kbuild, I'd rather like to see a new Kconfig symbol for
that flag (some CONFIG_EXT_MOD_NO_RECORD_GCC_SWITCHES) but a Kconfig
symbol only for external kmods feels odd to me, too.

HTH.

Kind regards,
Nicolas

Re: [PATCH v2] kstack_erase: suppress -grecord-gcc-switches for external module builds

[Nathan Chancellor]

On Fri, Aug 14, 2026 at 08:23:02PM +0200, Nicolas Schier wrote:
> If there is a need for external kmods to to have 
> 
>   make modules KCFLAGS=-gno-record-gcc-switches

Ah yeah, I forgot about KCFLAGS for the external module build. An
external module could also include

  ccflags-y := -gno-record-gcc-switches

in its build file as well if this is a requirement of their build setup.
Perhaps we could revisit this within Kbuild if there is enough interest
from various parties.

-- 
Cheers,
Nathan

RE: [PATCH v2] kstack_erase: suppress -grecord-gcc-switches for external module builds

[Jaihind Yadav]

  Hi Nicolas, Nathan, Kees,

  Thanks for the feedback.

  Would it be acceptable to handle this generically for external modules in
  top-level kbuild (`Makefile`) instead of tying it to kstack_erase? I was
  thinking about adding:

    diff --git a/Makefile b/Makefile
    @@ -1057,6 +1057,10 @@ include $(addprefix $(srctree)/, $(include-y))
     # Do not add $(call cc-option,...) below this line. When you build the kernel
     # from the clean source tree, the GCC plugins do not exist at this point.

    +ifneq ($(KBUILD_EXTMOD),)
    +KBUILD_CFLAGS += -gno-record-gcc-switches
    +endif
    +
     # Add user supplied CPPFLAGS, AFLAGS, CFLAGS and RUSTFLAGS as the last assignments

  This would avoid per-module changes and also avoid coupling a generic
  compiler switch-recording behavior to `CONFIG_GCC_PLUGIN_STACKLEAK`.

  If this direction looks reasonable, I can send it as an RFC patch for review.

  Thanks,
  Jaihind

-----Original Message-----
From: Nathan Chancellor <nathan@kernel.org> 
Sent: Saturday, August 15, 2026 4:16 AM
To: Nicolas Schier <nsc@kernel.org>
Cc: Jaihind Yadav <jaihindy@qti.qualcomm.com>; Kees Cook <kees@kernel.org>; linux-kbuild@vger.kernel.org; linux-modules@vger.kernel.org; linux-hardening@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] kstack_erase: suppress -grecord-gcc-switches for external module builds

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

On Fri, Aug 14, 2026 at 08:23:02PM +0200, Nicolas Schier wrote:
> If there is a need for external kmods to to have
>
>   make modules KCFLAGS=-gno-record-gcc-switches

Ah yeah, I forgot about KCFLAGS for the external module build. An external module could also include

  ccflags-y := -gno-record-gcc-switches

in its build file as well if this is a requirement of their build setup.
Perhaps we could revisit this within Kbuild if there is enough interest from various parties.

--
Cheers,
Nathan

Re: [PATCH v2] kstack_erase: suppress -grecord-gcc-switches for external module builds

[Nathan Chancellor]

Hi Jaihind,

On Sun, Aug 16, 2026 at 08:11:01AM +0000, Jaihind Yadav wrote:
>   Would it be acceptable to handle this generically for external modules in
>   top-level kbuild (`Makefile`) instead of tying it to kstack_erase? I was
>   thinking about adding:
> 
>     diff --git a/Makefile b/Makefile
>     @@ -1057,6 +1057,10 @@ include $(addprefix $(srctree)/, $(include-y))
>      # Do not add $(call cc-option,...) below this line. When you build the kernel
>      # from the clean source tree, the GCC plugins do not exist at this point.
> 
>     +ifneq ($(KBUILD_EXTMOD),)
>     +KBUILD_CFLAGS += -gno-record-gcc-switches
>     +endif
>     +
>      # Add user supplied CPPFLAGS, AFLAGS, CFLAGS and RUSTFLAGS as the last assignments
> 
>   This would avoid per-module changes and also avoid coupling a generic
>   compiler switch-recording behavior to `CONFIG_GCC_PLUGIN_STACKLEAK`.
> 
>   If this direction looks reasonable, I can send it as an RFC patch for review.

I do find this direction to get more at the heart of the problem but
shouldn't this live in scripts/Makefile.gcc-plugins?

diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
index b0e1423b09c2..9b9899580571 100644
--- a/scripts/Makefile.gcc-plugins
+++ b/scripts/Makefile.gcc-plugins
@@ -8,6 +8,10 @@ ifdef CONFIG_GCC_PLUGIN_LATENT_ENTROPY
 endif
 export DISABLE_LATENT_ENTROPY_PLUGIN
 
+# Disable recording GCC options in debug info when building external modules to
+# avoid leaking absolute host build paths
+gcc-plugin-cflags-$(if $(KBUILD_EXTMOD),y) += -gno-record-gcc-switches
+
 # All the plugin CFLAGS are collected here in case a build target needs to
 # filter them out of the KBUILD_CFLAGS.
 GCC_PLUGINS_CFLAGS := $(strip $(addprefix -fplugin=$(objtree)/scripts/gcc-plugins/, $(gcc-plugin-y)) $(gcc-plugin-cflags-y)) -DGCC_PLUGINS
--

Otherwise, this would apply to every external module build, not just
ones that enable GCC plugins.

I defer to Kees on whether this is actually acceptable though.

-- 
Cheers,
Nathan