[PATCH v3 1/4] kbuild: rust: Define probing macros for rustc

[PATCH v3 1/4] kbuild: rust: Define probing macros for rustc

[Matthew Maurer]

Creates flag probe macro variants for `rustc`. These are helpful
because:

1. `rustc` support will soon be a minimum rather than a pinned version.
2. We already support multiple LLVMs linked into `rustc`, and these are
   needed to probe what LLVM parameters `rustc` will accept.

Signed-off-by: Matthew Maurer <mmaurer@google.com>
---
 scripts/Kconfig.include   |  8 ++++++++
 scripts/Makefile.compiler | 15 +++++++++++++++
 2 files changed, 23 insertions(+)

diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
index 3ee8ecfb8c04..ffafe269fe9e 100644
--- a/scripts/Kconfig.include
+++ b/scripts/Kconfig.include
@@ -63,3 +63,11 @@ ld-version := $(shell,set -- $(ld-info) && echo $2)
 cc-option-bit = $(if-success,$(CC) -Werror $(1) -E -x c /dev/null -o /dev/null,$(1))
 m32-flag := $(cc-option-bit,-m32)
 m64-flag := $(cc-option-bit,-m64)
+
+# $(rustc-option,<flag>)
+# Return y if the Rust compiler supports <flag>, n otherwise
+# Calls to this should be guarded so that they are not evaluated if
+# CONFIG_HAVE_RUST is not set.
+# If you are testing for unstable features, consider `rustc-min-version`
+# instead, as features may have different completeness while available.
+rustc-option = $(success,trap "rm -rf .tmp_$$" EXIT; mkdir .tmp_$$; $(RUSTC) $(1) --crate-type=rlib /dev/null -o .tmp_$$/tmp.rlib)
diff --git a/scripts/Makefile.compiler b/scripts/Makefile.compiler
index 92be0c9a13ee..485d66768a32 100644
--- a/scripts/Makefile.compiler
+++ b/scripts/Makefile.compiler
@@ -72,3 +72,18 @@ clang-min-version = $(call test-ge, $(CONFIG_CLANG_VERSION), $1)
 # ld-option
 # Usage: KBUILD_LDFLAGS += $(call ld-option, -X, -Y)
 ld-option = $(call try-run, $(LD) $(KBUILD_LDFLAGS) $(1) -v,$(1),$(2),$(3))
+
+# __rustc-option
+# Usage: MY_RUSTFLAGS += $(call __rustc-option,$(RUSTC),$(MY_RUSTFLAGS),-Cinstrument-coverage,-Zinstrument-coverage)
+__rustc-option = $(call try-run,\
+	$(1) $(2) $(3) --crate-type=rlib /dev/null -o "$$TMP",$(3),$(4))
+
+# rustc-option
+# Usage: rustflags-y += $(call rustc-option,-Cinstrument-coverage,-Zinstrument-coverage)
+rustc-option = $(call __rustc-option, $(RUSTC),\
+	$(KBUILD_RUSTFLAGS),$(1),$(2))
+
+# rustc-option-yn
+# Usage: flag := $(call rustc-option-yn,-Cinstrument-coverage)
+rustc-option-yn = $(call try-run,\
+	$(RUSTC) $(KBUILD_RUSTFLAGS) $(1) --crate-type=rlib /dev/null -o "$$TMP",y,n)
-- 
2.46.0.184.g6999bdac58-goog

[PATCH v3 2/4] kbuild: rust: Enable KASAN support

[Matthew Maurer]

Rust supports KASAN via LLVM, but prior to this patch, the flags aren't
set properly.

Rust hasn't yet enabled software-tagged KWHASAN (only regular HWASAN),
so explicitly prevent Rust from being selected when it is enabled.

Suggested-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Matthew Maurer <mmaurer@google.com>
---
 scripts/Makefile.kasan          | 54 +++++++++++++++++++++++----------
 scripts/Makefile.lib            |  3 ++
 scripts/generate_rust_target.rs |  1 +
 3 files changed, 42 insertions(+), 16 deletions(-)

diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan
index aab4154af00a..163640fdefa0 100644
--- a/scripts/Makefile.kasan
+++ b/scripts/Makefile.kasan
@@ -12,6 +12,11 @@ endif
 KASAN_SHADOW_OFFSET ?= $(CONFIG_KASAN_SHADOW_OFFSET)
 
 cc-param = $(call cc-option, -mllvm -$(1), $(call cc-option, --param $(1)))
+rustc-param = $(call rustc-option, -Cllvm-args=-$(1),)
+
+check-args = $(foreach arg,$(2),$(call $(1),$(arg)))
+
+kasan_params :=
 
 ifdef CONFIG_KASAN_STACK
 	stack_enable := 1
@@ -41,39 +46,56 @@ CFLAGS_KASAN := $(call cc-option, -fsanitize=kernel-address \
 		$(call cc-option, -fsanitize=kernel-address \
 		-mllvm -asan-mapping-offset=$(KASAN_SHADOW_OFFSET)))
 
-# Now, add other parameters enabled similarly in both GCC and Clang.
-# As some of them are not supported by older compilers, use cc-param.
-CFLAGS_KASAN += $(call cc-param,asan-instrumentation-with-call-threshold=$(call_threshold)) \
-		$(call cc-param,asan-stack=$(stack_enable)) \
-		$(call cc-param,asan-instrument-allocas=1) \
-		$(call cc-param,asan-globals=1)
+# The minimum supported `rustc` version has a minimum supported LLVM
+# version late enough that we can assume support for -asan-mapping-offset
+RUSTFLAGS_KASAN := -Zsanitizer=kernel-address \
+		   -Zsanitizer-recover=kernel-address \
+		   -Cllvm-args=-asan-mapping-offset=$(KASAN_SHADOW_OFFSET)
+
+# Now, add other parameters enabled similarly in GCC, Clang, and rustc.
+# As some of them are not supported by older compilers, these will be filtered
+# through `cc-param` or `rust-param` as applicable.
+kasan_params += asan-instrumentation-with-call-threshold=$(call_threshold) \
+		asan-stack=$(stack_enable) \
+		asan-instrument-allocas=1 \
+		asan-globals=1
 
 # Instrument memcpy/memset/memmove calls by using instrumented __asan_mem*()
 # instead. With compilers that don't support this option, compiler-inserted
 # memintrinsics won't be checked by KASAN on GENERIC_ENTRY architectures.
-CFLAGS_KASAN += $(call cc-param,asan-kernel-mem-intrinsic-prefix=1)
+kasan_params += asan-kernel-mem-intrinsic-prefix=1
 
 endif # CONFIG_KASAN_GENERIC
 
 ifdef CONFIG_KASAN_SW_TAGS
 
 ifdef CONFIG_KASAN_INLINE
-	instrumentation_flags := $(call cc-param,hwasan-mapping-offset=$(KASAN_SHADOW_OFFSET))
+	kasan_params += hwasan-mapping-offset=$(KASAN_SHADOW_OFFSET)
 else
-	instrumentation_flags := $(call cc-param,hwasan-instrument-with-calls=1)
+	kasan_params += hwasan-instrument-with-calls=1
 endif
 
-CFLAGS_KASAN := -fsanitize=kernel-hwaddress \
-		$(call cc-param,hwasan-instrument-stack=$(stack_enable)) \
-		$(call cc-param,hwasan-use-short-granules=0) \
-		$(call cc-param,hwasan-inline-all-checks=0) \
-		$(instrumentation_flags)
+kasan_params += hwasan-instrument-stack=$(stack_enable) \
+		hwasan-use-short-granules=0 \
+		hwasan-inline-all-checks=0
+
+CFLAGS_KASAN := -fsanitize=kernel-hwaddress
+RUSTFLAGS_KASAN := -Zsanitizer=kernel-hwaddress \
+		   -Zsanitizer-recover=kernel-hwaddress
 
 # Instrument memcpy/memset/memmove calls by using instrumented __hwasan_mem*().
 ifeq ($(call clang-min-version, 150000)$(call gcc-min-version, 130000),y)
-	CFLAGS_KASAN += $(call cc-param,hwasan-kernel-mem-intrinsic-prefix=1)
+	kasan_params += hwasan-kernel-mem-intrinsic-prefix=1
 endif
 
 endif # CONFIG_KASAN_SW_TAGS
 
-export CFLAGS_KASAN CFLAGS_KASAN_NOSANITIZE
+# Add all as-supported KASAN LLVM parameters requested by the configuration
+CFLAGS_KASAN += $(call check-args, cc-param, $(kasan_params))
+
+ifdef CONFIG_RUST
+	# Avoid calling `rustc-param` unless Rust is enabled.
+	RUSTFLAGS_KASAN += $(call check-args, rustc-param, $(kasan_params))
+endif # CONFIG_RUST
+
+export CFLAGS_KASAN CFLAGS_KASAN_NOSANITIZE RUSTFLAGS_KASAN
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 9f06f6aaf7fc..4a58636705e0 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -167,6 +167,9 @@ ifneq ($(CONFIG_KASAN_HW_TAGS),y)
 _c_flags += $(if $(patsubst n%,, \
 		$(KASAN_SANITIZE_$(target-stem).o)$(KASAN_SANITIZE)$(is-kernel-object)), \
 		$(CFLAGS_KASAN), $(CFLAGS_KASAN_NOSANITIZE))
+_rust_flags += $(if $(patsubst n%,, \
+		$(KASAN_SANITIZE_$(target-stem).o)$(KASAN_SANITIZE)$(is-kernel-object)), \
+		$(RUSTFLAGS_KASAN))
 endif
 endif
 
diff --git a/scripts/generate_rust_target.rs b/scripts/generate_rust_target.rs
index ced405d35c5d..c24c2abd67db 100644
--- a/scripts/generate_rust_target.rs
+++ b/scripts/generate_rust_target.rs
@@ -192,6 +192,7 @@ fn main() {
         }
         ts.push("features", features);
         ts.push("llvm-target", "x86_64-linux-gnu");
+        ts.push("supported-sanitizers", ["kernel-address"]);
         ts.push("target-pointer-width", "64");
     } else if cfg.has("LOONGARCH") {
         panic!("loongarch uses the builtin rustc loongarch64-unknown-none-softfloat target");
-- 
2.46.0.184.g6999bdac58-goog

Re: [PATCH v3 1/4] kbuild: rust: Define probing macros for rustc

[Miguel Ojeda]

Hi Matthew,

On Mon, Aug 19, 2024 at 11:35 PM Matthew Maurer <mmaurer@google.com> wrote:
>
> Creates flag probe macro variants for `rustc`. These are helpful
> because:
>
> 1. `rustc` support will soon be a minimum rather than a pinned version.
> 2. We already support multiple LLVMs linked into `rustc`, and these are
>    needed to probe what LLVM parameters `rustc` will accept.
>
> Signed-off-by: Matthew Maurer <mmaurer@google.com>

I had some feedback on v2 -- was it missed?

    https://lore.kernel.org/rust-for-linux/CANiq72khUrha-a+59KYZgc63w-3P9=Dp_fs=+sgmV_A17q+PTA@mail.gmail.com/

Thanks!

Cheers,
Miguel

Re: [PATCH v3 1/4] kbuild: rust: Define probing macros for rustc

[Matthew Maurer]

On Tue, Aug 20, 2024 at 7:20 AM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:

>
> I had some feedback on v2 -- was it missed?
>
>     https://lore.kernel.org/rust-for-linux/CANiq72khUrha-a+59KYZgc63w-3P9=Dp_fs=+sgmV_A17q+PTA@mail.gmail.com/

Sorry, I did miss that in the refresh. To respond to a few points
before I send up a replacement for this patch:

>>
>> 1. `rustc` support will soon be a minimum rather than a pinned version.
> In the meantime, this happened, so we should update this sentence.

Will update.

>> 2. We already support multiple LLVMs linked into `rustc`, and these are
> I guess you mean `rustc` is able to use multiple major versions of
> LLVM -- or what do you mean by "multiple LLVMs linked"?

I meant that the `rustc` consumed by the kernel build may use a wide
range of different LLVMs, including unreleased ones. This means that
which options are valid fundamentally needs to be probed - there's not
necessarily a clean "LLVM version" for us to use. I'll rephrase.

>> +# $(rustc-option,<flag>)
>> +# Return y if the Rust compiler supports <flag>, n otherwise
>> +# Calls to this should be guarded so that they are not evaluated if
>> +# CONFIG_HAVE_RUST is not set.

>Hmm... why `HAVE_RUST`? Should that be `RUST_IS_AVAILABLE`? Or what is
t>he intention? Perhaps a comment would help here -- e.g. something
>like the comment I used in the original approach [1]. Otherwise we
>will forget... :)

Yes, this should be RUST_IS_AVAILABLE, will update.

>Also, I guess you wanted to relax the precondition as much as
>possible, which is great, just to double check, do we expect a case
>outside `RUST=y`?

I expect this to be potentially used for whether you're *allowed* to
set `RUST=y` - for example, if a particular sanitizer is enabled, you
may need to probe whether Rust+LLVM supports that sanitizer before
allowing RUST to be set to y.

>> rustc-option = $(success,trap "rm -rf .tmp_$$" EXIT; mkdir .tmp_$$; $(RUSTC) $(1) --crate-type=rlib /dev/null -o .tmp_$$/tmp.rlib)

>I also had `out-dir` [1] since, if I remember correctly, `rustc` may
>create temporary files in a potentially read-only location even in
>this case.

OK, I will add that.

>> Also, should we do `-Dwarnings` here?

I don't think so - I can't think of a case where we'd want to error on
a warning from an empty crate (though that may be a failure of
imagination.) Do you have an example of a warning we might trip that
we'd want to make the build reject an option's availability?

>
> Thanks!
>
> Cheers,
> Miguel

Re: [PATCH v3 2/4] kbuild: rust: Enable KASAN support

[Andrey Konovalov]

On Mon, Aug 19, 2024 at 11:35 PM Matthew Maurer <mmaurer@google.com> wrote:
>
> Rust supports KASAN via LLVM, but prior to this patch, the flags aren't
> set properly.
>
> Rust hasn't yet enabled software-tagged KWHASAN (only regular HWASAN),
> so explicitly prevent Rust from being selected when it is enabled.

This is done in the next patch, not in this one.

> Suggested-by: Miguel Ojeda <ojeda@kernel.org>
> Signed-off-by: Matthew Maurer <mmaurer@google.com>
> ---
>  scripts/Makefile.kasan          | 54 +++++++++++++++++++++++----------
>  scripts/Makefile.lib            |  3 ++
>  scripts/generate_rust_target.rs |  1 +
>  3 files changed, 42 insertions(+), 16 deletions(-)
>
> diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan
> index aab4154af00a..163640fdefa0 100644
> --- a/scripts/Makefile.kasan
> +++ b/scripts/Makefile.kasan
> @@ -12,6 +12,11 @@ endif
>  KASAN_SHADOW_OFFSET ?= $(CONFIG_KASAN_SHADOW_OFFSET)
>
>  cc-param = $(call cc-option, -mllvm -$(1), $(call cc-option, --param $(1)))
> +rustc-param = $(call rustc-option, -Cllvm-args=-$(1),)
> +
> +check-args = $(foreach arg,$(2),$(call $(1),$(arg)))
> +
> +kasan_params :=
>
>  ifdef CONFIG_KASAN_STACK
>         stack_enable := 1
> @@ -41,39 +46,56 @@ CFLAGS_KASAN := $(call cc-option, -fsanitize=kernel-address \
>                 $(call cc-option, -fsanitize=kernel-address \
>                 -mllvm -asan-mapping-offset=$(KASAN_SHADOW_OFFSET)))
>
> -# Now, add other parameters enabled similarly in both GCC and Clang.
> -# As some of them are not supported by older compilers, use cc-param.
> -CFLAGS_KASAN += $(call cc-param,asan-instrumentation-with-call-threshold=$(call_threshold)) \
> -               $(call cc-param,asan-stack=$(stack_enable)) \
> -               $(call cc-param,asan-instrument-allocas=1) \
> -               $(call cc-param,asan-globals=1)
> +# The minimum supported `rustc` version has a minimum supported LLVM
> +# version late enough that we can assume support for -asan-mapping-offset

Nit: dot at the end.

> +RUSTFLAGS_KASAN := -Zsanitizer=kernel-address \
> +                  -Zsanitizer-recover=kernel-address \
> +                  -Cllvm-args=-asan-mapping-offset=$(KASAN_SHADOW_OFFSET)
> +
> +# Now, add other parameters enabled similarly in GCC, Clang, and rustc.
> +# As some of them are not supported by older compilers, these will be filtered
> +# through `cc-param` or `rust-param` as applicable.
> +kasan_params += asan-instrumentation-with-call-threshold=$(call_threshold) \
> +               asan-stack=$(stack_enable) \
> +               asan-instrument-allocas=1 \
> +               asan-globals=1
>
>  # Instrument memcpy/memset/memmove calls by using instrumented __asan_mem*()
>  # instead. With compilers that don't support this option, compiler-inserted
>  # memintrinsics won't be checked by KASAN on GENERIC_ENTRY architectures.
> -CFLAGS_KASAN += $(call cc-param,asan-kernel-mem-intrinsic-prefix=1)
> +kasan_params += asan-kernel-mem-intrinsic-prefix=1
>
>  endif # CONFIG_KASAN_GENERIC
>
>  ifdef CONFIG_KASAN_SW_TAGS
>
>  ifdef CONFIG_KASAN_INLINE
> -       instrumentation_flags := $(call cc-param,hwasan-mapping-offset=$(KASAN_SHADOW_OFFSET))
> +       kasan_params += hwasan-mapping-offset=$(KASAN_SHADOW_OFFSET)
>  else
> -       instrumentation_flags := $(call cc-param,hwasan-instrument-with-calls=1)
> +       kasan_params += hwasan-instrument-with-calls=1
>  endif
>
> -CFLAGS_KASAN := -fsanitize=kernel-hwaddress \
> -               $(call cc-param,hwasan-instrument-stack=$(stack_enable)) \
> -               $(call cc-param,hwasan-use-short-granules=0) \
> -               $(call cc-param,hwasan-inline-all-checks=0) \
> -               $(instrumentation_flags)
> +kasan_params += hwasan-instrument-stack=$(stack_enable) \
> +               hwasan-use-short-granules=0 \
> +               hwasan-inline-all-checks=0

Let's put these kasan_params parts after CFLAGS_KASAN.

> +
> +CFLAGS_KASAN := -fsanitize=kernel-hwaddress
> +RUSTFLAGS_KASAN := -Zsanitizer=kernel-hwaddress \
> +                  -Zsanitizer-recover=kernel-hwaddress

What's the intention of defining RUSTFLAGS_KASAN for SW_TAGS if it's
not supported by Rust? Should this be removed?

If this is just a foundation for potential future support of
Rust+SW_TAGS, please add a comment explaining this. And also please
put the patch that disallows Rust+SW_TAGS before this one, if you keep
RUSTFLAGS_KASAN.

>  # Instrument memcpy/memset/memmove calls by using instrumented __hwasan_mem*().
>  ifeq ($(call clang-min-version, 150000)$(call gcc-min-version, 130000),y)
> -       CFLAGS_KASAN += $(call cc-param,hwasan-kernel-mem-intrinsic-prefix=1)
> +       kasan_params += hwasan-kernel-mem-intrinsic-prefix=1
>  endif
>
>  endif # CONFIG_KASAN_SW_TAGS
>
> -export CFLAGS_KASAN CFLAGS_KASAN_NOSANITIZE
> +# Add all as-supported KASAN LLVM parameters requested by the configuration

Nit: dot at the end.


> +CFLAGS_KASAN += $(call check-args, cc-param, $(kasan_params))
> +
> +ifdef CONFIG_RUST
> +       # Avoid calling `rustc-param` unless Rust is enabled.
> +       RUSTFLAGS_KASAN += $(call check-args, rustc-param, $(kasan_params))
> +endif # CONFIG_RUST
> +
> +export CFLAGS_KASAN CFLAGS_KASAN_NOSANITIZE RUSTFLAGS_KASAN
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 9f06f6aaf7fc..4a58636705e0 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -167,6 +167,9 @@ ifneq ($(CONFIG_KASAN_HW_TAGS),y)
>  _c_flags += $(if $(patsubst n%,, \
>                 $(KASAN_SANITIZE_$(target-stem).o)$(KASAN_SANITIZE)$(is-kernel-object)), \
>                 $(CFLAGS_KASAN), $(CFLAGS_KASAN_NOSANITIZE))
> +_rust_flags += $(if $(patsubst n%,, \
> +               $(KASAN_SANITIZE_$(target-stem).o)$(KASAN_SANITIZE)$(is-kernel-object)), \
> +               $(RUSTFLAGS_KASAN))
>  endif
>  endif
>
> diff --git a/scripts/generate_rust_target.rs b/scripts/generate_rust_target.rs
> index ced405d35c5d..c24c2abd67db 100644
> --- a/scripts/generate_rust_target.rs
> +++ b/scripts/generate_rust_target.rs
> @@ -192,6 +192,7 @@ fn main() {
>          }
>          ts.push("features", features);
>          ts.push("llvm-target", "x86_64-linux-gnu");
> +        ts.push("supported-sanitizers", ["kernel-address"]);
>          ts.push("target-pointer-width", "64");
>      } else if cfg.has("LOONGARCH") {
>          panic!("loongarch uses the builtin rustc loongarch64-unknown-none-softfloat target");
> --
> 2.46.0.184.g6999bdac58-goog
>

Re: [PATCH v3 1/4] kbuild: rust: Define probing macros for rustc

[Miguel Ojeda]

On Tue, Aug 20, 2024 at 7:22 PM Matthew Maurer <mmaurer@google.com> wrote:
>
> Sorry, I did miss that in the refresh. To respond to a few points
> before I send up a replacement for this patch:

No problem at all -- thanks!

> I expect this to be potentially used for whether you're *allowed* to
> set `RUST=y` - for example, if a particular sanitizer is enabled, you
> may need to probe whether Rust+LLVM supports that sanitizer before
> allowing RUST to be set to y.

Yeah, makes sense if we do the dependency that way.

> I don't think so - I can't think of a case where we'd want to error on
> a warning from an empty crate (though that may be a failure of
> imagination.) Do you have an example of a warning we might trip that
> we'd want to make the build reject an option's availability?

IIRC back then I was thinking about something like the "unknown target
feature forwarded to backend" one, i.e. to identify whether a target
feature was supported or not. However, that is not a warning even
under `-Dwarning`s (https://github.com/rust-lang/rust/issues/91262)
unless something recently changed.

We can add it if/when we need it.

Cheers,
Miguel