linux-kernel - Re: [PATCH] kbuild: userprogs: use correct linker when mixing clang and GNU ld

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250724231025.GA3620641@ax162>
Date: Thu, 24 Jul 2025 16:10:25 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
Cc: Masahiro Yamada <masahiroy@...nel.org>,
	Nicolas Schier <nicolas.schier@...ux.dev>,
	Nick Desaulniers <nick.desaulniers+lkml@...il.com>,
	Bill Wendling <morbo@...gle.com>,
	Justin Stitt <justinstitt@...gle.com>, linux-kbuild@...r.kernel.org,
	linux-kernel@...r.kernel.org, llvm@...ts.linux.dev,
	stable@...r.kernel.org
Subject: Re: [PATCH] kbuild: userprogs: use correct linker when mixing clang
 and GNU ld

On Thu, Jul 24, 2025 at 10:32:45AM +0200, Thomas Weißschuh wrote:
> The userprogs infrastructure does not expect clang being used with GNU ld
> and in that case uses /usr/bin/ld for linking, not the configured $(LD).
> This fallback is problematic as it will break when cross-compiling.
> Mixing clang and GNU ld is used for example when building for SPARC64,
> as ld.lld is not sufficient; see Documentation/kbuild/llvm.rst.
> 
> Relax the check around --ld-path so it gets used for all linkers.
> 
> Fixes: dfc1b168a8c4 ("kbuild: userprogs: use correct lld when linking through clang")
> Cc: stable@...r.kernel.org
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
> ---
> Nathan, you originally proposed the check for $(CONFIG_LD_IS_LLD) [0],
> could you take a look at this?

I would expect this to be okay but I have not explicitly tested it. I
had not considered the case of GNU ld being used since aside from
sparc64, there is not another architecture that supports clang but not
ld.lld.

Reviewed-by: Nathan Chancellor <nathan@...nel.org>

> ---
>  Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Makefile b/Makefile
> index c09766beb7eff4780574682b8ea44475fc0a5188..e300c6546c845c300edb5f0033719963c7da8f9b 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1134,7 +1134,7 @@ KBUILD_USERCFLAGS  += $(filter -m32 -m64 --target=%, $(KBUILD_CPPFLAGS) $(KBUILD
>  KBUILD_USERLDFLAGS += $(filter -m32 -m64 --target=%, $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS))

Does KBUILD_USERCFLAGS respect LLVM_IAS? sparc64 does not use the
integrated assembler yet (as far as I am aware) so I think we probably
need to filter '--prefix=' and '-fno-integrated-as' to avoid further
issues with assembling?

>  # userspace programs are linked via the compiler, use the correct linker
> -ifeq ($(CONFIG_CC_IS_CLANG)$(CONFIG_LD_IS_LLD),yy)
> +ifneq ($(CONFIG_CC_IS_CLANG),)

At this point, I think this can just become

  ifdef CONFIG_CC_IS_CLANG

>  KBUILD_USERLDFLAGS += --ld-path=$(LD)
>  endif
>  
> 
> ---
> base-commit: 6832a9317eee280117cd695fa885b2b7a7a38daf
> change-id: 20250723-userprogs-clang-gnu-ld-7a1c16fc852d
> 
> Best regards,
> -- 
> Thomas Weißschuh <thomas.weissschuh@...utronix.de>
>