[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