[PATCH v3 0/4] Rust KASAN Support

[PATCH v3 0/4] Rust KASAN Support

[Matthew Maurer]

Right now, if we turn on KASAN, Rust code will cause violations because
it's not enabled properly.

This series:
1. Adds flag probe macros for Rust - now that we're setting a minimum rustc
   version instead of an exact one, these could be useful in general. We need
   them in this patch because we don't set a restriction on which LLVM rustc
   is using, which is what KASAN actually cares about.
2. Makes `rustc` enable the relevant KASAN sanitizer flags when C does.
3. Adds a smoke test to the `kasan_test` KUnit suite to check basic
   integration.

This patch series requires the target.json array support patch [1] as
the x86_64 target.json file currently produced does not mark itself as KASAN
capable, and is rebased on top of the KASAN Makefile rewrite [2].

Differences from v2 [3]:
1. Rebased on top of the maintainer's cleanup of the Makefile.
2. Cleaned up the UaF test based on feedback.
3. Calls out that KASAN_SW_TAGS is not yet supported in the config.

The notable piece of feedback I have not followed is in the renaming of
kasan_test.c to kasan_test_c.c - this was done in order to allow the
module to be named kasan_test but consist of two .o files. The other
options I see are renaming the test suite or creating a separate Rust
test suite, but both of those seemed more invasive than the rename. Let
me know if you have another approach you'd prefer there.

[1] https://lore.kernel.org/lkml/20240730-target-json-arrays-v1-1-2b376fd0ecf4@google.com/
[2] https://lore.kernel.org/all/20240813224027.84503-1-andrey.konovalov@linux.dev
[3] https://lore.kernel.org/all/20240812232910.2026387-1-mmaurer@google.com/


Matthew Maurer (4):
  kbuild: rust: Define probing macros for rustc
  kbuild: rust: Enable KASAN support
  rust: kasan: Rust does not support KHWASAN
  kasan: rust: Add KASAN smoke test via UAF

 init/Kconfig                              |  1 +
 mm/kasan/Makefile                         |  9 +++-
 mm/kasan/kasan.h                          |  1 +
 mm/kasan/{kasan_test.c => kasan_test_c.c} | 11 +++++
 mm/kasan/kasan_test_rust.rs               | 19 ++++++++
 scripts/Kconfig.include                   |  8 ++++
 scripts/Makefile.compiler                 | 15 +++++++
 scripts/Makefile.kasan                    | 54 ++++++++++++++++-------
 scripts/Makefile.lib                      |  3 ++
 scripts/generate_rust_target.rs           |  1 +
 10 files changed, 105 insertions(+), 17 deletions(-)
 rename mm/kasan/{kasan_test.c => kasan_test_c.c} (99%)
 create mode 100644 mm/kasan/kasan_test_rust.rs

-- 
2.46.0.184.g6999bdac58-goog

[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 0/4] Rust KASAN Support

[Miguel Ojeda]

On Mon, Aug 19, 2024 at 11:35 PM Matthew Maurer <mmaurer@google.com> wrote:
>
> This patch series requires the target.json array support patch [1] as
> the x86_64 target.json file currently produced does not mark itself as KASAN
> capable, and is rebased on top of the KASAN Makefile rewrite [2].
>
> Differences from v2 [3]:
> 1. Rebased on top of the maintainer's cleanup of the Makefile.

Andrey/KASAN: whenever you are happy with this series, assuming it
happens for this cycle, do you have a preference/constraint where to
land this through? I am asking since we will likely need the
target.json patch for another series that may land this cycle too
(Rust KCFI). I asked Masahiro as well what he preferred to do, e.g. if
he wants to take everything (KCFI, KASAN, SCS) through Kbuild, that is
great too.

Thanks!

Cheers,
Miguel

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 0/4] Rust KASAN Support

[Andrey Konovalov]

On Tue, Aug 20, 2024 at 4:20 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Mon, Aug 19, 2024 at 11:35 PM Matthew Maurer <mmaurer@google.com> wrote:
> >
> > This patch series requires the target.json array support patch [1] as
> > the x86_64 target.json file currently produced does not mark itself as KASAN
> > capable, and is rebased on top of the KASAN Makefile rewrite [2].
> >
> > Differences from v2 [3]:
> > 1. Rebased on top of the maintainer's cleanup of the Makefile.
>
> Andrey/KASAN: whenever you are happy with this series, assuming it
> happens for this cycle, do you have a preference/constraint where to
> land this through? I am asking since we will likely need the
> target.json patch for another series that may land this cycle too
> (Rust KCFI). I asked Masahiro as well what he preferred to do, e.g. if
> he wants to take everything (KCFI, KASAN, SCS) through Kbuild, that is
> great too.

No preferences, feel free to take this through any tree. Thanks!

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 0/4] Rust KASAN Support

[Alice Ryhl]

On 8/19/24 11:35 PM, Matthew Maurer wrote:
> The notable piece of feedback I have not followed is in the renaming of
> kasan_test.c to kasan_test_c.c - this was done in order to allow the
> module to be named kasan_test but consist of two .o files. The other
> options I see are renaming the test suite or creating a separate Rust
> test suite, but both of those seemed more invasive than the rename. Let
> me know if you have another approach you'd prefer there.

If you're sending another version anyway, then it would make sense to 
mention why the file is renamed in the commit message of that patch.

Alice

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