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

[Nicolas Schier <nsc@kernel.org>]

[ 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