[PATCH 0/1] scripts: kstack_erase: avoid absolute stackleak plugin path

[PATCH 0/1] scripts: kstack_erase: avoid absolute stackleak plugin path

[Jaihind Yadav]

Use a relative -fplugin path for CONFIG_KSTACK_ERASE stackleak plugin
invocation to avoid embedding absolute build paths in recorded compiler
switch metadata.

Jaihind Yadav (1):
  scripts: kstack_erase: use relative stackleak plugin path

 scripts/Makefile.kstack_erase | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

-- 
2.43.0

[PATCH 1/1] scripts: kstack_erase: use relative stackleak plugin path

[Jaihind Yadav]

GCC records full compiler command lines in DWARF producer strings by\ndefault. With CONFIG_KSTACK_ERASE, the stackleak plugin is currently\npassed using an absolute -fplugin path, which can leak host-specific\nbuild paths into debug artifacts.\n\nResolve the stackleak plugin directory relative to the current build\ndirectory and use that in the -fplugin option, falling back to the\nexisting absolute objtree path when needed.\n\nThis keeps plugin loading behavior unchanged while avoiding absolute\nworkspace paths in recorded compiler flags.

Signed-off-by: Jaihind Yadav <jaihindy@qti.qualcomm.com>
---
 scripts/Makefile.kstack_erase | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/scripts/Makefile.kstack_erase b/scripts/Makefile.kstack_erase
index ee7e4ef7b8926..006d10f3b77a0 100644
--- a/scripts/Makefile.kstack_erase
+++ b/scripts/Makefile.kstack_erase
@@ -1,7 +1,10 @@
 # SPDX-License-Identifier: GPL-2.0
 
 ifdef CONFIG_GCC_PLUGIN_STACKLEAK
-kstack-erase-cflags-y += -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
+stackleak-plugin-dir := $(or \
+	$(shell realpath -m --relative-to=$(CURDIR) $(objtree)/scripts/gcc-plugins 2>/dev/null), \
+	$(objtree)/scripts/gcc-plugins)
+kstack-erase-cflags-y += -fplugin=$(stackleak-plugin-dir)/stackleak_plugin.so
 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
-- 
2.43.0

Re: [PATCH 1/1] scripts: kstack_erase: use relative stackleak plugin path

[Nicolas Schier]

[-- Attachment #1: Type: text/plain, Size: 2180 bytes --]

Hi Jaihind,

On Mon, Jul 20, 2026 at 03:05:45PM +0530, Jaihind Yadav wrote:
> GCC records full compiler command lines in DWARF producer strings by\ndefault. With CONFIG_KSTACK_ERASE, the stackleak plugin is currently\npassed using an absolute -fplugin path, which can leak host-specific\nbuild paths into debug artifacts.\n\nResolve the stackleak plugin directory relative to the current build\ndirectory and use that in the -fplugin option, falling back to the\nexisting absolute objtree path when needed.\n\nThis keeps plugin loading behavior unchanged while avoiding absolute\nworkspace paths in recorded compiler flags.

Please note: while the patch below is applicable, your commit message is 
broken ("\n" instead of newlines).




Can you give me a hint on how to reproduce the described behaviour?
I enabled

CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_INFO_DWARF5=y
CONFIG_KSTACK_ERASE=y

and built with O=build but cannot find the path to the plugin dir in any 
binary build artifact I grep'ed.  What do I have to do to find the 
plugin path there?

[...]
> diff --git a/scripts/Makefile.kstack_erase b/scripts/Makefile.kstack_erase
> index ee7e4ef7b8926..006d10f3b77a0 100644
> --- a/scripts/Makefile.kstack_erase
> +++ b/scripts/Makefile.kstack_erase
> @@ -1,7 +1,10 @@
>  # SPDX-License-Identifier: GPL-2.0
>  
>  ifdef CONFIG_GCC_PLUGIN_STACKLEAK
> -kstack-erase-cflags-y += -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
> +stackleak-plugin-dir := $(or \
> +	$(shell realpath -m --relative-to=$(CURDIR) $(objtree)/scripts/gcc-plugins 2>/dev/null), \
> +	$(objtree)/scripts/gcc-plugins)
> +kstack-erase-cflags-y += -fplugin=$(stackleak-plugin-dir)/stackleak_plugin.so

As Kbuild changes the working directory to KBUILD_OUTPUT build dir for 
compilation, I'd assume that '$(objtree)/' should just be removed and 
scripts/gcc-plugins/stackleak_plugin.so be the always matching relative 
path to the plugin:

-kstack-erase-cflags-y += -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
+kstack-erase-cflags-y += -fplugin=scripts/gcc-plugins/stackleak_plugin.so

Does that work for you?

Kind regards,
Nicolas

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

RE: [PATCH 1/1] scripts: kstack_erase: use relative stackleak plugin path

[Jaihind Yadav]

Hi Nicolas Schier,

Thanks for looking into this and for the suggestion.

The issue is only observable when building out-of-tree kernel modules with CONFIG_KSTACK_ERASE=y enabled. I did not notice the problem for in-tree kernel objects.

As an example, in our setup msm_kgsl.ko is built as an out-of-tree module. The absolute path to the stackleak plugin gets embedded into the DWARF producer string and consequently appears in the generated module:

readelf --debug-dump=info \
./tmp/work/<machine_name>-qcom-linux/kgsl-dlkm/0.0+git/image/usr/lib/modules/6.18.0-rc6-00263-g3d5db6797b5f/updates/msm_kgsl.ko \
| grep fplugin | tail

Output:
DW_AT_producer : GNU C11 15.2.0 ... \
-fplugin=/local/mnt/workspace/abhi/QLI-MAINLINE/build/tmp/work-shared/target-ride-sx/kernel-build-artifacts/scripts/gcc-plugins/stackleak_plugin.so \
-fplugin-arg-stackleak_plugin-track-min-size=100 ...


As can be seen above, the full build path to stackleak_plugin.so is recorded in the DWARF metadata of the out-of-tree module.

I have not yet tried your proposed simplification:

-kstack-erase-cflags-y += -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
+kstack-erase-cflags-y += -fplugin=scripts/gcc-plugins/stackleak_plugin.so


At first glance it does seem reasonable given that Kbuild changes the working directory to KBUILD_OUTPUT during compilation. Please Let me try this approach with the out-of-tree module build and I'll report back with the results.

Thanks again for the suggestion.

Thanks &  Regards,
Jaihind Yadav


-----Original Message-----
From: Nicolas Schier <n.schier@fritz.com> 
Sent: Wednesday, July 22, 2026 8:16 PM
To: Jaihind Yadav <jaihindy@qti.qualcomm.com>
Cc: nathan@kernel.org; kees@kernel.org; linux-kbuild@vger.kernel.org; linux-hardening@vger.kernel.org; gustavoars@kernel.org; linux-kernel@vger.kernel.org; nsc@kernel.org
Subject: Re: [PATCH 1/1] scripts: kstack_erase: use relative stackleak plugin path

Hi Jaihind,

On Mon, Jul 20, 2026 at 03:05:45PM +0530, Jaihind Yadav wrote:
> GCC records full compiler command lines in DWARF producer strings by\ndefault. With CONFIG_KSTACK_ERASE, the stackleak plugin is currently\npassed using an absolute -fplugin path, which can leak host-specific\nbuild paths into debug artifacts.\n\nResolve the stackleak plugin directory relative to the current build\ndirectory and use that in the -fplugin option, falling back to the\nexisting absolute objtree path when needed.\n\nThis keeps plugin loading behavior unchanged while avoiding absolute\nworkspace paths in recorded compiler flags.

Please note: while the patch below is applicable, your commit message is broken ("\n" instead of newlines).




Can you give me a hint on how to reproduce the described behaviour?
I enabled

CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_INFO_DWARF5=y
CONFIG_KSTACK_ERASE=y

and built with O=build but cannot find the path to the plugin dir in any 
binary build artifact I grep'ed.  What do I have to do to find the 
plugin path there?

[...]
> diff --git a/scripts/Makefile.kstack_erase b/scripts/Makefile.kstack_erase
> index ee7e4ef7b8926..006d10f3b77a0 100644
> --- a/scripts/Makefile.kstack_erase
> +++ b/scripts/Makefile.kstack_erase
> @@ -1,7 +1,10 @@
>  # SPDX-License-Identifier: GPL-2.0
>  
>  ifdef CONFIG_GCC_PLUGIN_STACKLEAK
> -kstack-erase-cflags-y += -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
> +stackleak-plugin-dir := $(or \
> +	$(shell realpath -m --relative-to=$(CURDIR) $(objtree)/scripts/gcc-plugins 2>/dev/null), \
> +	$(objtree)/scripts/gcc-plugins)
> +kstack-erase-cflags-y += -fplugin=$(stackleak-plugin-dir)/stackleak_plugin.so

As Kbuild changes the working directory to KBUILD_OUTPUT build dir for 
compilation, I'd assume that '$(objtree)/' should just be removed and 
scripts/gcc-plugins/stackleak_plugin.so be the always matching relative 
path to the plugin:

-kstack-erase-cflags-y += -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
+kstack-erase-cflags-y += -fplugin=scripts/gcc-plugins/stackleak_plugin.so

Does that work for you?

Kind regards,
Nicolas

RE: [PATCH 1/1] scripts: kstack_erase: use relative stackleak plugin path

[Jaihind Yadav]

Hi Nicolas Schier,

Thanks for the suggestion. I tested the proposed change:

-kstack-erase-cflags-y += -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
+kstack-erase-cflags-y += -fplugin=scripts/gcc-plugins/stackleak_plugin.so


Unfortunately, it does not work for the out-of-tree module builds in my environment.

With this change, in-tree kernel objects build successfully, but external kernel modules fail because GCC is unable to locate the plugin. For example, I see the following error when building out-of-tree modules such as qps615-dlkm, kgsl-dlkm, and camx-dlkm:

cc1: error: cannot load plugin scripts/gcc-plugins/stackleak_plugin.so:
scripts/gcc-plugins/stackleak_plugin.so: cannot open shared object file:
No such file or directory


The original issue I reported is specific to out-of-tree modules. When CONFIG_KSTACK_ERASE=y is enabled, the absolute path to stackleak_plugin.so gets recorded in the DWARF producer string. For example:

-fplugin=/local/mnt/workspace/abhi/QLI-MAINLINE/build/tmp/work-shared/target-ride-sx/kernel-build-artifacts/scripts/gcc-plugins/stackleak_plugin.so


gets embedded into the debug metadata of the generated module.

Given that the proposed relative path breaks out-of-tree module builds, could you please take a look at the patch I posted? If the approach looks reasonable, I would appreciate your review and consideration for merging it.

Thank you for your time and feedback.

Thanks and  regards,
 Jaihind Yadav

-----Original Message-----
From: Jaihind Yadav 
Sent: Wednesday, July 22, 2026 10:48 PM
To: 'Nicolas Schier' <n.schier@fritz.com>
Cc: nathan@kernel.org; kees@kernel.org; linux-kbuild@vger.kernel.org; linux-hardening@vger.kernel.org; gustavoars@kernel.org; linux-kernel@vger.kernel.org; nsc@kernel.org
Subject: RE: [PATCH 1/1] scripts: kstack_erase: use relative stackleak plugin path


Hi Nicolas Schier,

Thanks for looking into this and for the suggestion.

The issue is only observable when building out-of-tree kernel modules with CONFIG_KSTACK_ERASE=y enabled. I did not notice the problem for in-tree kernel objects.

As an example, in our setup msm_kgsl.ko is built as an out-of-tree module. The absolute path to the stackleak plugin gets embedded into the DWARF producer string and consequently appears in the generated module:

readelf --debug-dump=info \
./tmp/work/<machine_name>-qcom-linux/kgsl-dlkm/0.0+git/image/usr/lib/modules/6.18.0-rc6-00263-g3d5db6797b5f/updates/msm_kgsl.ko \
| grep fplugin | tail

Output:
DW_AT_producer : GNU C11 15.2.0 ... \
-fplugin=/local/mnt/workspace/abhi/QLI-MAINLINE/build/tmp/work-shared/target-ride-sx/kernel-build-artifacts/scripts/gcc-plugins/stackleak_plugin.so \
-fplugin-arg-stackleak_plugin-track-min-size=100 ...


As can be seen above, the full build path to stackleak_plugin.so is recorded in the DWARF metadata of the out-of-tree module.

I have not yet tried your proposed simplification:

-kstack-erase-cflags-y += -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
+kstack-erase-cflags-y += 
+-fplugin=scripts/gcc-plugins/stackleak_plugin.so


At first glance it does seem reasonable given that Kbuild changes the working directory to KBUILD_OUTPUT during compilation. Please Let me try this approach with the out-of-tree module build and I'll report back with the results.

Thanks again for the suggestion.

Thanks &  Regards,
Jaihind Yadav


-----Original Message-----
From: Nicolas Schier <n.schier@fritz.com>
Sent: Wednesday, July 22, 2026 8:16 PM
To: Jaihind Yadav <jaihindy@qti.qualcomm.com>
Cc: nathan@kernel.org; kees@kernel.org; linux-kbuild@vger.kernel.org; linux-hardening@vger.kernel.org; gustavoars@kernel.org; linux-kernel@vger.kernel.org; nsc@kernel.org
Subject: Re: [PATCH 1/1] scripts: kstack_erase: use relative stackleak plugin path

Hi Jaihind,

On Mon, Jul 20, 2026 at 03:05:45PM +0530, Jaihind Yadav wrote:
> GCC records full compiler command lines in DWARF producer strings by\ndefault. With CONFIG_KSTACK_ERASE, the stackleak plugin is currently\npassed using an absolute -fplugin path, which can leak host-specific\nbuild paths into debug artifacts.\n\nResolve the stackleak plugin directory relative to the current build\ndirectory and use that in the -fplugin option, falling back to the\nexisting absolute objtree path when needed.\n\nThis keeps plugin loading behavior unchanged while avoiding absolute\nworkspace paths in recorded compiler flags.

Please note: while the patch below is applicable, your commit message is broken ("\n" instead of newlines).




Can you give me a hint on how to reproduce the described behaviour?
I enabled

CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_INFO_DWARF5=y
CONFIG_KSTACK_ERASE=y

and built with O=build but cannot find the path to the plugin dir in any binary build artifact I grep'ed.  What do I have to do to find the plugin path there?

[...]
> diff --git a/scripts/Makefile.kstack_erase 
> b/scripts/Makefile.kstack_erase index ee7e4ef7b8926..006d10f3b77a0 
> 100644
> --- a/scripts/Makefile.kstack_erase
> +++ b/scripts/Makefile.kstack_erase
> @@ -1,7 +1,10 @@
>  # SPDX-License-Identifier: GPL-2.0
>  
>  ifdef CONFIG_GCC_PLUGIN_STACKLEAK
> -kstack-erase-cflags-y += 
> -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
> +stackleak-plugin-dir := $(or \
> +	$(shell realpath -m --relative-to=$(CURDIR) $(objtree)/scripts/gcc-plugins 2>/dev/null), \
> +	$(objtree)/scripts/gcc-plugins)
> +kstack-erase-cflags-y += 
> +-fplugin=$(stackleak-plugin-dir)/stackleak_plugin.so

As Kbuild changes the working directory to KBUILD_OUTPUT build dir for compilation, I'd assume that '$(objtree)/' should just be removed and scripts/gcc-plugins/stackleak_plugin.so be the always matching relative path to the plugin:

-kstack-erase-cflags-y += -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
+kstack-erase-cflags-y += 
+-fplugin=scripts/gcc-plugins/stackleak_plugin.so

Does that work for you?

Kind regards,
Nicolas

Re: [PATCH 1/1] scripts: kstack_erase: use relative stackleak plugin path

[Nicolas Schier]

On Wed, Jul 22, 2026 at 07:00:43PM +0000, Jaihind Yadav wrote:
> 
> Hi Nicolas Schier,
> 
> Thanks for the suggestion. I tested the proposed change:
> 
> -kstack-erase-cflags-y += -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
> +kstack-erase-cflags-y += -fplugin=scripts/gcc-plugins/stackleak_plugin.so
> 
> 
> Unfortunately, it does not work for the out-of-tree module builds in
> my environment.

Thanks for checking; and yes I forgot out-of-tree modules.  When
building them, Kbuild changes to their respective output directory so my
suggestion had to fail for oot kmods.

[...]
> Given that the proposed relative path breaks out-of-tree module
> builds, could you please take a look at the patch I posted? If the
> approach looks reasonable, I would appreciate your review and
> consideration for merging it.

I am not sure, if we can take your path, as 'readlink --relative-to' is
only available in coreutils/Linux but coreutils are not a documented
requirement for Linux builds (cp. Documentation/process/changes.rst),
thus this would probably kill Linux builds on BSDs and Darwin/MacOS.

But let me think about that a few days;  and perhaps someone else comes
up with an idea.

Kind regards,
Nicolas

Re: [PATCH 1/1] scripts: kstack_erase: use relative stackleak plugin path

[Nathan Chancellor]

On Fri, Jul 24, 2026 at 10:18:57PM +0200, Nicolas Schier wrote:
> On Wed, Jul 22, 2026 at 07:00:43PM +0000, Jaihind Yadav wrote:
> > 
> > Hi Nicolas Schier,
> > 
> > Thanks for the suggestion. I tested the proposed change:
> > 
> > -kstack-erase-cflags-y += -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
> > +kstack-erase-cflags-y += -fplugin=scripts/gcc-plugins/stackleak_plugin.so
> > 
> > 
> > Unfortunately, it does not work for the out-of-tree module builds in
> > my environment.
> 
> Thanks for checking; and yes I forgot out-of-tree modules.  When
> building them, Kbuild changes to their respective output directory so my
> suggestion had to fail for oot kmods.

Technically, this is only a problem for out of tree kernel modules,
right? When building in-tree kernel modules, objtree is always '.', so
we will never have the output directory path in the debug information
(at least based on my brief testing).

> > Given that the proposed relative path breaks out-of-tree module
> > builds, could you please take a look at the patch I posted? If the
> > approach looks reasonable, I would appreciate your review and
> > consideration for merging it.
> 
> I am not sure, if we can take your path, as 'readlink --relative-to' is
> only available in coreutils/Linux but coreutils are not a documented
> requirement for Linux builds (cp. Documentation/process/changes.rst),
> thus this would probably kill Linux builds on BSDs and Darwin/MacOS.
> 
> But let me think about that a few days;  and perhaps someone else comes
> up with an idea.

Yeah, I don't really like 'realpath --relative-to' either, it feels a
bit like a hack since it will only avoid including a full path if the
module output directory includes part of the build directory. For
example:

  O=/mnt/build/kernel
  MO=/mnt/build/extmod

$ realpath -m --relative-to /mnt/build/extmod /mnt/build/kernel
../kernel

vs.

  O=/home/nathan/build/kernel
  MO=/mnt/build/extmod

$ realpath -m --relative-to /mnt/build/extmod /home/nathan/build/kernel
../../../home/nathan/build/kernel

Furthermore, this patch only fixes KSTACK_ERASE but we have other GCC
plugins that presumably have the same problem.

I do not have a good solution for this either but since it only affects
external kernel modules, I am not particularly inclined to think too
hard about it.

-- 
Cheers,
Nathan

RE: [PATCH 1/1] scripts: kstack_erase: use relative stackleak plugin path

[Jaihind Yadav]

Hi Nathan And Nicolas ,

Thanks for the feedback.

I took another look at this and experimented with a different approach for external modules:

diff --git a/scripts/Makefile.kstack_erase b/scripts/Makefile.kstack_erase
index ee7e4ef7b892..xxxxxxxxxxxx 100644
--- a/scripts/Makefile.kstack_erase
+++ b/scripts/Makefile.kstack_erase
@@ -5,6 +5,10 @@ kstack-erase-cflags-y += -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
 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
+ifneq ($(KBUILD_EXTMOD),)
+# Avoid embedding absolute -fplugin paths into external module DWARF metadata.
+kstack-erase-cflags-y += -gno-record-gcc-switches
+endif
 DISABLE_KSTACK_ERASE := -fplugin-arg-stackleak_plugin-disable
 endif

In my testing, this prevents the absolute stackleak plugin path specified via

    -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so

from being recorded in the DWARF information of out-of-tree modules, while avoiding the use of platform-specific utilities such as realpath/readlink --relative-to.

I agree this does not solve the broader issue for all GCC plugins, but it appears to address the specific KSTACK_ERASE case that originally motivated the discussion.

Would this direction be more acceptable than the previous relative-path approach, or would suppressing GCC switch recording for external modules be considered undesirable from a debugging-information perspective?

Thanks,
Jaihind

-----Original Message-----
From: Nathan Chancellor <nathan@kernel.org> 
Sent: Monday, August 3, 2026 11:42 PM
To: Nicolas Schier <nsc@kernel.org>
Cc: Jaihind Yadav <jaihindy@qti.qualcomm.com>; kees@kernel.org; linux-kbuild@vger.kernel.org; linux-hardening@vger.kernel.org; gustavoars@kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] scripts: kstack_erase: use relative stackleak plugin path

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

On Fri, Jul 24, 2026 at 10:18:57PM +0200, Nicolas Schier wrote:
> On Wed, Jul 22, 2026 at 07:00:43PM +0000, Jaihind Yadav wrote:
> >
> > Hi Nicolas Schier,
> >
> > Thanks for the suggestion. I tested the proposed change:
> >
> > -kstack-erase-cflags-y += 
> > -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
> > +kstack-erase-cflags-y += 
> > +-fplugin=scripts/gcc-plugins/stackleak_plugin.so
> >
> >
> > Unfortunately, it does not work for the out-of-tree module builds in 
> > my environment.
>
> Thanks for checking; and yes I forgot out-of-tree modules.  When 
> building them, Kbuild changes to their respective output directory so 
> my suggestion had to fail for oot kmods.

Technically, this is only a problem for out of tree kernel modules, right? When building in-tree kernel modules, objtree is always '.', so we will never have the output directory path in the debug information (at least based on my brief testing).

> > Given that the proposed relative path breaks out-of-tree module 
> > builds, could you please take a look at the patch I posted? If the 
> > approach looks reasonable, I would appreciate your review and 
> > consideration for merging it.
>
> I am not sure, if we can take your path, as 'readlink --relative-to' 
> is only available in coreutils/Linux but coreutils are not a 
> documented requirement for Linux builds (cp. 
> Documentation/process/changes.rst),
> thus this would probably kill Linux builds on BSDs and Darwin/MacOS.
>
> But let me think about that a few days;  and perhaps someone else 
> comes up with an idea.

Yeah, I don't really like 'realpath --relative-to' either, it feels a bit like a hack since it will only avoid including a full path if the module output directory includes part of the build directory. For
example:

  O=/mnt/build/kernel
  MO=/mnt/build/extmod

$ realpath -m --relative-to /mnt/build/extmod /mnt/build/kernel ../kernel

vs.

  O=/home/nathan/build/kernel
  MO=/mnt/build/extmod

$ realpath -m --relative-to /mnt/build/extmod /home/nathan/build/kernel ../../../home/nathan/build/kernel

Furthermore, this patch only fixes KSTACK_ERASE but we have other GCC plugins that presumably have the same problem.

I do not have a good solution for this either but since it only affects external kernel modules, I am not particularly inclined to think too hard about it.

--
Cheers,
Nathan

Re: [PATCH 1/1] scripts: kstack_erase: use relative stackleak plugin path

[Nathan Chancellor]

On Wed, Aug 12, 2026 at 10:55:38AM +0000, Jaihind Yadav wrote:
> Hi Nathan And Nicolas ,
> 
> Thanks for the feedback.
> 
> I took another look at this and experimented with a different approach for external modules:
> 
> diff --git a/scripts/Makefile.kstack_erase b/scripts/Makefile.kstack_erase
> index ee7e4ef7b892..xxxxxxxxxxxx 100644
> --- a/scripts/Makefile.kstack_erase
> +++ b/scripts/Makefile.kstack_erase
> @@ -5,6 +5,10 @@ kstack-erase-cflags-y += -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
>  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
> +ifneq ($(KBUILD_EXTMOD),)
> +# Avoid embedding absolute -fplugin paths into external module DWARF metadata.
> +kstack-erase-cflags-y += -gno-record-gcc-switches
> +endif
>  DISABLE_KSTACK_ERASE := -fplugin-arg-stackleak_plugin-disable
>  endif
> 
> In my testing, this prevents the absolute stackleak plugin path specified via
> 
>     -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
> 
> from being recorded in the DWARF information of out-of-tree modules, while avoiding the use of platform-specific utilities such as realpath/readlink --relative-to.
> 
> I agree this does not solve the broader issue for all GCC plugins, but it appears to address the specific KSTACK_ERASE case that originally motivated the discussion.
> 
> Would this direction be more acceptable than the previous relative-path approach, or would suppressing GCC switch recording for external modules be considered undesirable from a debugging-information perspective?

This seems more reasonable to me. You could save a couple of lines by
making it

  kstack-erase-cflags-$(if $(KBUILD_EXTMOD),y) += -gno-record-gcc-switches

but I guess that is personal style. I doubt it would hamper debugging to
have this done unconditionally but we could always revisit it if someone
complains.

-- 
Cheers,
Nathan

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

[Jaihind Yadav]

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.

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
 DISABLE_KSTACK_ERASE := -fplugin-arg-stackleak_plugin-disable
 endif
 
-- 
2.43.0

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

[Kees Cook]

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
>  DISABLE_KSTACK_ERASE := -fplugin-arg-stackleak_plugin-disable
>  endif
>  
> -- 
> 2.43.0
> 
> 

-- 
Kees Cook

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

[Jaihind Yadav]

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.

  Given that, I scoped the change to the kstack_erase use case that
  originally triggered the discussion. If a broader solution is preferred,
  I'm happy to explore that direction as well.

  Nathan, does the scoped approach still look reasonable to you?
  Kees, if this scoped fix looks acceptable, could you please review it for
  merge?

  Thanks,
  Jaihind

-----Original Message-----
From: Kees Cook <kees@kernel.org> 
Sent: Thursday, August 13, 2026 10:13 PM
To: Jaihind Yadav <jaihindy@qti.qualcomm.com>
Cc: nathan@kernel.org; nsc@kernel.org; linux-kbuild@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 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_TRA
> CK_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
>  DISABLE_KSTACK_ERASE := -fplugin-arg-stackleak_plugin-disable
>  endif
>
> --
> 2.43.0
>
>

--
Kees Cook

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