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: <20250904-sterilize-swagger-c7999b124e83@spud>
Date: Thu, 4 Sep 2025 13:27:53 +0100
From: Conor Dooley <conor@...nel.org>
To: Asuna Yang <spriteovo@...il.com>
Cc: Jason Montleon <jmontleo@...hat.com>, Han Gao <rabenda.cn@...il.com>,
	Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>,
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <lossin@...nel.org>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
	Danilo Krummrich <dakr@...nel.org>,
	Jonathan Corbet <corbet@....net>,
	Paul Walmsley <paul.walmsley@...ive.com>,
	Palmer Dabbelt <palmer@...belt.com>,
	Albert Ou <aou@...s.berkeley.edu>, Alexandre Ghiti <alex@...ti.fr>,
	Masahiro Yamada <masahiroy@...nel.org>,
	Nathan Chancellor <nathan@...nel.org>,
	Nick Desaulniers <nick.desaulniers+lkml@...il.com>,
	Bill Wendling <morbo@...gle.com>,
	Justin Stitt <justinstitt@...gle.com>, Tejun Heo <tj@...nel.org>,
	Kees Cook <kees@...nel.org>, Peter Zijlstra <peterz@...radead.org>,
	Matthew Maurer <mmaurer@...gle.com>, Jeff Xu <jeffxu@...omium.org>,
	Shakeel Butt <shakeel.butt@...ux.dev>,
	Jan Hendrik Farr <kernel@...rr.cc>,
	Michal Koutný <mkoutny@...e.com>,
	Christian Brauner <brauner@...nel.org>,
	Brian Gerst <brgerst@...il.com>, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
	linux-kbuild@...r.kernel.org, llvm@...ts.linux.dev
Subject: Re: [PATCH 2/2] RISC-V: re-enable gcc + rust builds

On Wed, Sep 03, 2025 at 09:07:57PM +0200, Asuna Yang wrote:
> Commit 33549fcf37ec ("RISC-V: disallow gcc + rust builds") disabled GCC
> + Rust builds for RISC-V due to differences in extension handling
> compared to LLVM.
> 
> Add a Kconfig non-visible symbol to ensure that all important RISC-V
> specific flags that will be used by GCC can be correctly recognized by
> Rust bindgen's libclang, otherwise config HAVE_RUST will not be
> selected.
> 
> Signed-off-by: Asuna Yang <SpriteOvO@...il.com>

Thanks for working on this. One thing - please don't send new versions
of patchsets in response to earlier versions or other threads. It
doesn't do you any favours with mailbox visibility.

> ---
>  Documentation/rust/arch-support.rst |  2 +-
>  arch/riscv/Kconfig                  | 62 ++++++++++++++++++++++++++++-
>  rust/Makefile                       |  7 +++-
>  3 files changed, 68 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/rust/arch-support.rst b/Documentation/rust/arch-support.rst
> index 6e6a515d0899..5282e0e174e8 100644
> --- a/Documentation/rust/arch-support.rst
> +++ b/Documentation/rust/arch-support.rst
> @@ -18,7 +18,7 @@ Architecture   Level of support  Constraints
>  ``arm``        Maintained        ARMv7 Little Endian only.
>  ``arm64``      Maintained        Little Endian only.
>  ``loongarch``  Maintained        \-
> -``riscv``      Maintained        ``riscv64`` and LLVM/Clang only.
> +``riscv``      Maintained        ``riscv64`` only.
>  ``um``         Maintained        \-
>  ``x86``        Maintained        ``x86_64`` only.
>  =============  ================  ==============================================
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 1c5544401530..d7f421e0f429 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -195,7 +195,7 @@ config RISCV
>  	select HAVE_REGS_AND_STACK_ACCESS_API
>  	select HAVE_RETHOOK if !XIP_KERNEL
>  	select HAVE_RSEQ
> -	select HAVE_RUST if RUSTC_SUPPORTS_RISCV && CC_IS_CLANG
> +	select HAVE_RUST if RUSTC_SUPPORTS_RISCV && RUST_BINDGEN_LIBCLANG_RECOGNIZES_FLAGS
>  	select HAVE_SAMPLE_FTRACE_DIRECT
>  	select HAVE_SAMPLE_FTRACE_DIRECT_MULTI
>  	select HAVE_STACKPROTECTOR
> @@ -236,6 +236,27 @@ config RUSTC_SUPPORTS_RISCV
>  	# -Zsanitizer=shadow-call-stack flag.
>  	depends on !SHADOW_CALL_STACK || RUSTC_VERSION >= 108200
>  
> +config RUST_BINDGEN_LIBCLANG_RECOGNIZES_FLAGS
> +	def_bool y
> +	depends on RUST_BINDGEN_LIBCLANG_RECOGNIZES_V
> +	depends on RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZABHA
> +	depends on RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZACAS
> +	depends on RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZBA
> +	depends on RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZBB
> +	depends on RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZBC
> +	depends on RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZBKB
> +	depends on RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZICSR_ZIFENCEI

Other than Zicsr/Zifencei that may need explicit handling in a dedicated
option, the approach here seems kinda backwards.
Individually these symbols don't actually mean what they say they do,
which is confusing: "recognises" here is true even when it may not be
true at all because TOOLCHAIN_HAS_FOO is not set. Why can these options
not be removed, and instead the TOOLCHAIN_HAS_FOO options grow a
"depends on !RUST || <condition>"?

> +	help
> +	  Rust bindgen currently relies on libclang as backend. When a mixed build is
> +	  performed (building C code with GCC), GCC flags will be passed to libclang.
> +	  However, not all GCC flags are recognized by Clang, so most of the
> +	  incompatible flags have been filtered out in rust/Makefile.
> +
> +	  For RISC-V, GCC and Clang are not at the same pace of implementing extensions.
> +	  This config ensures that all important RISC-V specific flags that will be
> +	  used by GCC can be correctly recognized by Rust bindgen's libclang, otherwise
> +	  config HAVE_RUST will not be selected.
> +
>  config CLANG_SUPPORTS_DYNAMIC_FTRACE
>  	def_bool CC_IS_CLANG
>  	# https://github.com/ClangBuiltLinux/linux/issues/1817
> @@ -634,6 +655,11 @@ config TOOLCHAIN_HAS_V
>  	depends on LLD_VERSION >= 140000 || LD_VERSION >= 23800
>  	depends on AS_HAS_OPTION_ARCH
>  
> +config RUST_BINDGEN_LIBCLANG_RECOGNIZES_V
> +	def_bool y
> +	# https://github.com/llvm/llvm-project/commit/e6de53b4de4aecca4ac892500a0907805896ed27
> +	depends on !TOOLCHAIN_HAS_V || RUST_BINDGEN_LIBCLANG_VERSION >= 140000
> +
>  config RISCV_ISA_V
>  	bool "Vector extension support"
>  	depends on TOOLCHAIN_HAS_V
> @@ -698,6 +724,11 @@ config TOOLCHAIN_HAS_ZABHA
>  	depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zabha)
>  	depends on AS_HAS_OPTION_ARCH
>  
> +config RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZABHA
> +	def_bool y
> +	# https://github.com/llvm/llvm-project/commit/6b7444964a8d028989beee554a1f5c61d16a1cac
> +	depends on !TOOLCHAIN_HAS_ZABHA || RUST_BINDGEN_LIBCLANG_VERSION >= 190100
> +
>  config RISCV_ISA_ZABHA
>  	bool "Zabha extension support for atomic byte/halfword operations"
>  	depends on TOOLCHAIN_HAS_ZABHA
> @@ -716,6 +747,11 @@ config TOOLCHAIN_HAS_ZACAS
>  	depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zacas)
>  	depends on AS_HAS_OPTION_ARCH
>  
> +config RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZACAS
> +	def_bool y
> +	# https://github.com/llvm/llvm-project/commit/614aeda93b2225c6eb42b00ba189ba7ca2585c60
> +	depends on !TOOLCHAIN_HAS_ZACAS || RUST_BINDGEN_LIBCLANG_VERSION >= 200100
> +
>  config RISCV_ISA_ZACAS
>  	bool "Zacas extension support for atomic CAS"
>  	depends on TOOLCHAIN_HAS_ZACAS
> @@ -735,6 +771,11 @@ config TOOLCHAIN_HAS_ZBB
>  	depends on LLD_VERSION >= 150000 || LD_VERSION >= 23900
>  	depends on AS_HAS_OPTION_ARCH
>  
> +config RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZBB
> +	def_bool y
> +	# https://github.com/llvm/llvm-project/commit/33d008b169f3c813a4a45da220d0952f795ac477
> +	depends on !TOOLCHAIN_HAS_ZBB || RUST_BINDGEN_LIBCLANG_VERSION >= 140000
> +
>  # This symbol indicates that the toolchain supports all v1.0 vector crypto
>  # extensions, including Zvk*, Zvbb, and Zvbc.  LLVM added all of these at once.
>  # binutils added all except Zvkb, then added Zvkb.  So we just check for Zvkb.
> @@ -750,6 +791,11 @@ config TOOLCHAIN_HAS_ZBA
>  	depends on LLD_VERSION >= 150000 || LD_VERSION >= 23900
>  	depends on AS_HAS_OPTION_ARCH
>  
> +config RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZBA
> +	def_bool y
> +	# https://github.com/llvm/llvm-project/commit/33d008b169f3c813a4a45da220d0952f795ac477
> +	depends on !TOOLCHAIN_HAS_ZBA || RUST_BINDGEN_LIBCLANG_VERSION >= 140000
> +
>  config RISCV_ISA_ZBA
>  	bool "Zba extension support for bit manipulation instructions"
>  	default y
> @@ -785,6 +831,11 @@ config TOOLCHAIN_HAS_ZBC
>  	depends on LLD_VERSION >= 150000 || LD_VERSION >= 23900
>  	depends on AS_HAS_OPTION_ARCH
>  
> +config RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZBC
> +	def_bool y
> +	# https://github.com/llvm/llvm-project/commit/33d008b169f3c813a4a45da220d0952f795ac477
> +	depends on !TOOLCHAIN_HAS_ZBC || RUST_BINDGEN_LIBCLANG_VERSION >= 140000
> +
>  config RISCV_ISA_ZBCawl
>  	bool "Zbc extension support for carry-less multiplication instructions"
>  	depends on TOOLCHAIN_HAS_ZBC
> @@ -808,6 +859,11 @@ config TOOLCHAIN_HAS_ZBKB
>  	depends on LLD_VERSION >= 150000 || LD_VERSION >= 23900
>  	depends on AS_HAS_OPTION_ARCH
>  
> +config RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZBKB
> +	def_bool y
> +	# https://github.com/llvm/llvm-project/commit/7ee1c162cc53d37f717f9a138276ad64fa6863bc
> +	depends on !TOOLCHAIN_HAS_ZBKB || RUST_BINDGEN_LIBCLANG_VERSION >= 140000
> +
>  config RISCV_ISA_ZBKB
>  	bool "Zbkb extension support for bit manipulation instructions"
>  	depends on TOOLCHAIN_HAS_ZBKB
> @@ -894,6 +950,10 @@ config TOOLCHAIN_NEEDS_OLD_ISA_SPEC
>  	  versions of clang and GCC to be passed to GAS, which has the same result
>  	  as passing zicsr and zifencei to -march.

> +config RUST_BINDGEN_LIBCLANG_RECOGNIZES_ZICSR_ZIFENCEI
> +	def_bool y
> +	depends on TOOLCHAIN_NEEDS_OLD_ISA_SPEC || (TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI && RUST_BINDGEN_LIBCLANG_VERSION >= 170000)

What does the libclang >= 17 requirement actually do here? Is that the
version where llvm starts to require that Zicsr/Zifencei is set in order
to use them? I think a comment to that effect is required if so. This
doesn't actually need to be blocking either, should just be able to
filter it out of march when passing to bindgen, no?

What about the case where TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI is not
set at all? Currently your patch is going to block rust in that case,
when actually nothing needs to be done at all - no part of the toolchain
requires understanding Zicsr/Zifencei as standalone extensions in this
case.

The TOOLCHAIN_NEEDS_OLD_ISA_SPEC handling I don't remember 100% how it
works, but if bindgen requires them to be set to use the extension
this will return true but do nothing to add the extensions to march?
That seems wrong to me.
I'd be fairly amenable to disabling rust though when used in combination
with gcc < 11.3 and gas >=2.36 since it's such a niche condition, rather
doing work to support it. That'd be effectively an inversion of your
first condition.

You could probably do something like blocking rust if
TOOLCHAIN_NEEDS_OLD_ISA_SPEC and where TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI
is set in combination with an older libclang - so like:

	select HAVE_RUST if FOO && !ZICSR_ZIFENCEI_MISMATCH

config ZICSR_ZIFENCEI_MISMATCH
	def_bool y
	depends on TOOLCHAIN_NEEDS_OLD_ISA_SPEC || (TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI && RUST_BINDGEN_LIBCLANG_VERSION < 170000)

or alternatively, make a Kconfig option for the later half of that
condition along the lines of:

config BINDGEN_FILTER_OUT_ZICSR_ZIFENCEI
	def_bool y
	depends on TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI && RUST_BINDGEN_LIBCLANG_VERSION < 170000

and use it to filter out _zicsr_zifencei and make the select

	select HAVE_RUST if FOO && !TOOLCHAIN_NEEDS_OLD_ISA_SPEC


FWIW the reason that these odd mixes have dedicated work done for them
in Kconfig is that the ?Linaro? CI infrastructure was running clang +
binutils builds with a version of LLVM that predated us having full
LLVM=1 support and it was done to stop that CI infrastructure falling
over constantly.

Cheers,
Conor.

> +
>  config FPU
>  	bool "FPU support"
>  	default y
> diff --git a/rust/Makefile b/rust/Makefile
> index 34d0429d50fd..7b1055c98146 100644
> --- a/rust/Makefile
> +++ b/rust/Makefile
> @@ -277,20 +277,25 @@ bindgen_skip_c_flags := -mno-fp-ret-in-387 -mpreferred-stack-boundary=% \
>  	-fno-inline-functions-called-once -fsanitize=bounds-strict \
>  	-fstrict-flex-arrays=% -fmin-function-alignment=% \
>  	-fzero-init-padding-bits=% -mno-fdpic \
> -	--param=% --param asan-%
> +	--param=% --param asan-% -mno-riscv-attribute
>  
>  # Derived from `scripts/Makefile.clang`.
>  BINDGEN_TARGET_x86	:= x86_64-linux-gnu
>  BINDGEN_TARGET_arm64	:= aarch64-linux-gnu
>  BINDGEN_TARGET_arm	:= arm-linux-gnueabi
>  BINDGEN_TARGET_loongarch	:= loongarch64-linux-gnusf
> +BINDGEN_TARGET_riscv	:= riscv64-linux-gnu
>  BINDGEN_TARGET_um	:= $(BINDGEN_TARGET_$(SUBARCH))
>  BINDGEN_TARGET		:= $(BINDGEN_TARGET_$(SRCARCH))
>  
> +ifeq ($(BINDGEN_TARGET),)
> +$(error add '--target=' option to rust/Makefile)
> +else
>  # All warnings are inhibited since GCC builds are very experimental,
>  # many GCC warnings are not supported by Clang, they may only appear in
>  # some configurations, with new GCC versions, etc.
>  bindgen_extra_c_flags = -w --target=$(BINDGEN_TARGET)
> +endif
>  
>  # Auto variable zero-initialization requires an additional special option with
>  # clang that is going to be removed sometime in the future (likely in
> -- 
> 2.51.0
> 

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ