| Message ID | 20240829-shadow-call-stack-v7-1-2f62a4432abf@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v7] rust: support for shadow call stack sanitizer | expand |
On Thu, Aug 29, 2024 at 10:23 AM Alice Ryhl <aliceryhl@google.com> wrote: > > Add all of the flags that are needed to support the shadow call stack > (SCS) sanitizer with Rust, and updates Kconfig to allow only > configurations that work. Applied to `rust-next` -- thanks everyone! Paul/Palmer/Albert/RISC-V: I think you were not Cc'd (at least in this version?), so please shout if you have a problem with this. [ Fixed indentation using spaces. - Miguel ] Cheers, Miguel
On Fri, Sep 13, 2024 at 12:08:20AM +0200, Miguel Ojeda wrote: > On Thu, Aug 29, 2024 at 10:23 AM Alice Ryhl <aliceryhl@google.com> wrote: > > > > Add all of the flags that are needed to support the shadow call stack > > (SCS) sanitizer with Rust, and updates Kconfig to allow only > > configurations that work. > > Applied to `rust-next` -- thanks everyone! > > Paul/Palmer/Albert/RISC-V: I think you were not Cc'd (at least in this > version?), so please shout if you have a problem with this. For some reason I deleted the series from my mailbox, must've been in dt-binding review mode and hit ctrl + d. I've been away and busy, so my apologies Alice for not trying this out sooner. It's sorta annoying to test rust + scs on riscv, cos you need (unless I am mistaken) llvm-19. llvm-18 + rust built fine, but has no SCS. llvm-19 + rust failed to build for me riscv, producing: In file included from /stuff/linux/rust/helpers/helpers.c:22: /stuff/linux/rust/helpers/spinlock.c:10:23: error: call to undeclared function 'spinlock_check'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] __raw_spin_lock_init(spinlock_check(lock), name, key, LD_WAIT_CONFIG); ^ /stuff/linux/rust/helpers/spinlock.c:10:23: error: incompatible integer to pointer conversion passing 'int' to parameter of type 'raw_spinlock_t *' (aka 'struct raw_spinlock *') [-Wint-conversion] __raw_spin_lock_init(spinlock_check(lock), name, key, LD_WAIT_CONFIG); ^~~~~~~~~~~~~~~~~~~~ /stuff/linux/include/linux/spinlock.h:101:52: note: passing argument to parameter 'lock' here extern void __raw_spin_lock_init(raw_spinlock_t *lock, const char *name, ^ 2 errors generated. This occurs because I have DEBUG_SPINLOCK enabled. I didn't check why, but Andreas seems to have introduced that code - luckily he's already on CC here :) With that disabled, there are dozens of warnings along the lines of: /stuff/linux/rust/helpers/err.c:6:14: warning: symbol 'rust_helper_ERR_PTR' was not declared. Should it be static? If those are okay for rust code, it would be rather helpful if the warnings could be disabled - otherwise they should really be fixed. Following that, I got a build error: error[E0425]: cannot find function `__mutex_init` in crate `bindings` --> /stuff/linux/rust/kernel/sync/lock/mutex.rs:104:28 | 104 | unsafe { bindings::__mutex_init(ptr, name, key) } | ^^^^^^^^^^^^ help: a function with a similar name exists: `__mutex_rt_init` | ::: /stuff/brsdk/work/linux/rust/bindings/bindings_generated.rs:12907:5 | 12907 | / pub fn __mutex_rt_init( 12908 | | lock: *mut mutex, 12909 | | name: *const core::ffi::c_char, 12910 | | key: *mut lock_class_key, 12911 | | ); | |_____- similarly named function `__mutex_rt_init` defined here error: aborting due to 1 previous error I stopped there, Space Marine 2 awaits. Hopefully I'll get to say hello next week, Conor.
On Fri, Sep 13, 2024 at 11:18 PM Conor Dooley <conor@kernel.org> wrote: > > On Fri, Sep 13, 2024 at 12:08:20AM +0200, Miguel Ojeda wrote: > > On Thu, Aug 29, 2024 at 10:23 AM Alice Ryhl <aliceryhl@google.com> wrote: > > > > > > Add all of the flags that are needed to support the shadow call stack > > > (SCS) sanitizer with Rust, and updates Kconfig to allow only > > > configurations that work. > > > > Applied to `rust-next` -- thanks everyone! > > > > Paul/Palmer/Albert/RISC-V: I think you were not Cc'd (at least in this > > version?), so please shout if you have a problem with this. > > For some reason I deleted the series from my mailbox, must've been in > dt-binding review mode and hit ctrl + d. I've been away and busy, so my > apologies Alice for not trying this out sooner. > It's sorta annoying to test rust + scs on riscv, cos you need (unless I > am mistaken) llvm-19. llvm-18 + rust built fine, but has no SCS. > > llvm-19 + rust failed to build for me riscv, producing: > > In file included from /stuff/linux/rust/helpers/helpers.c:22: > /stuff/linux/rust/helpers/spinlock.c:10:23: error: call to undeclared function 'spinlock_check'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] > __raw_spin_lock_init(spinlock_check(lock), name, key, LD_WAIT_CONFIG); > ^ > /stuff/linux/rust/helpers/spinlock.c:10:23: error: incompatible integer to pointer conversion passing 'int' to parameter of type 'raw_spinlock_t *' (aka 'struct raw_spinlock *') [-Wint-conversion] > __raw_spin_lock_init(spinlock_check(lock), name, key, LD_WAIT_CONFIG); > ^~~~~~~~~~~~~~~~~~~~ > /stuff/linux/include/linux/spinlock.h:101:52: note: passing argument to parameter 'lock' here > extern void __raw_spin_lock_init(raw_spinlock_t *lock, const char *name, > ^ > 2 errors generated. > > This occurs because I have DEBUG_SPINLOCK enabled. I didn't check why, > but Andreas seems to have introduced that code - luckily he's already on > CC here :) > > With that disabled, there are dozens of warnings along the lines of: > /stuff/linux/rust/helpers/err.c:6:14: warning: symbol 'rust_helper_ERR_PTR' was not declared. Should it be static? > If those are okay for rust code, it would be rather helpful if the > warnings could be disabled - otherwise they should really be fixed. > > Following that, I got a build error: > > error[E0425]: cannot find function `__mutex_init` in crate `bindings` > --> /stuff/linux/rust/kernel/sync/lock/mutex.rs:104:28 > | > 104 | unsafe { bindings::__mutex_init(ptr, name, key) } > | ^^^^^^^^^^^^ help: a function with a similar name exists: `__mutex_rt_init` > | > ::: /stuff/brsdk/work/linux/rust/bindings/bindings_generated.rs:12907:5 > | > 12907 | / pub fn __mutex_rt_init( > 12908 | | lock: *mut mutex, > 12909 | | name: *const core::ffi::c_char, > 12910 | | key: *mut lock_class_key, > 12911 | | ); > | |_____- similarly named function `__mutex_rt_init` defined here > > error: aborting due to 1 previous error This looks like an unrelated problem to me. This patch only changes the rustc flags, but these errors have to do with the Rust helpers/bindings, which get generated before the rustc flags are used at all. Most likely, there is a problem under the particular configuration you are using. Were you able to reproduce these errors without this patch? > I stopped there, Space Marine 2 awaits. > > Hopefully I'll get to say hello next week, > Conor. Thanks for taking a look, and see you at Plumbers! Alice
On Fri, Sep 13, 2024 at 11:44:26PM +0200, Alice Ryhl wrote: > On Fri, Sep 13, 2024 at 11:18 PM Conor Dooley <conor@kernel.org> wrote: > > > > On Fri, Sep 13, 2024 at 12:08:20AM +0200, Miguel Ojeda wrote: > > > On Thu, Aug 29, 2024 at 10:23 AM Alice Ryhl <aliceryhl@google.com> wrote: > > > > > > > > Add all of the flags that are needed to support the shadow call stack > > > > (SCS) sanitizer with Rust, and updates Kconfig to allow only > > > > configurations that work. > > > > > > Applied to `rust-next` -- thanks everyone! > > > > > > Paul/Palmer/Albert/RISC-V: I think you were not Cc'd (at least in this > > > version?), so please shout if you have a problem with this. > > error[E0425]: cannot find function `__mutex_init` in crate `bindings` > > --> /stuff/linux/rust/kernel/sync/lock/mutex.rs:104:28 > > | > > 104 | unsafe { bindings::__mutex_init(ptr, name, key) } > > | ^^^^^^^^^^^^ help: a function with a similar name exists: `__mutex_rt_init` > > | > > ::: /stuff/brsdk/work/linux/rust/bindings/bindings_generated.rs:12907:5 > > | > > 12907 | / pub fn __mutex_rt_init( > > 12908 | | lock: *mut mutex, > > 12909 | | name: *const core::ffi::c_char, > > 12910 | | key: *mut lock_class_key, > > 12911 | | ); > > | |_____- similarly named function `__mutex_rt_init` defined here > > > > error: aborting due to 1 previous error > > This looks like an unrelated problem to me. This patch only changes > the rustc flags, but these errors have to do with the Rust > helpers/bindings, which get generated before the rustc flags are used > at all. Most likely, there is a problem under the particular > configuration you are using. Were you able to reproduce these errors > without this patch? Oh I'm not blaming you for it, don't worry. I didn't think it would be related, but it did stop me from being trivially able to check whether there was any problems with the applied patch. I'll give it another go tomorrow, with all of the other rust code stripped out and just this patch applied.
On Fri, 13 Sep 2024 22:17:56 +0100 Conor Dooley <conor@kernel.org> wrote: > On Fri, Sep 13, 2024 at 12:08:20AM +0200, Miguel Ojeda wrote: > > On Thu, Aug 29, 2024 at 10:23 AM Alice Ryhl <aliceryhl@google.com> wrote: > > > > > > Add all of the flags that are needed to support the shadow call stack > > > (SCS) sanitizer with Rust, and updates Kconfig to allow only > > > configurations that work. > > > > Applied to `rust-next` -- thanks everyone! > > > > Paul/Palmer/Albert/RISC-V: I think you were not Cc'd (at least in this > > version?), so please shout if you have a problem with this. > > For some reason I deleted the series from my mailbox, must've been in > dt-binding review mode and hit ctrl + d. I've been away and busy, so my > apologies Alice for not trying this out sooner. > It's sorta annoying to test rust + scs on riscv, cos you need (unless I > am mistaken) llvm-19. llvm-18 + rust built fine, but has no SCS. > > llvm-19 + rust failed to build for me riscv, producing: > > In file included from /stuff/linux/rust/helpers/helpers.c:22: > /stuff/linux/rust/helpers/spinlock.c:10:23: error: call to undeclared function 'spinlock_check'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] > __raw_spin_lock_init(spinlock_check(lock), name, key, LD_WAIT_CONFIG); > ^ > /stuff/linux/rust/helpers/spinlock.c:10:23: error: incompatible integer to pointer conversion passing 'int' to parameter of type 'raw_spinlock_t *' (aka 'struct raw_spinlock *') [-Wint-conversion] > __raw_spin_lock_init(spinlock_check(lock), name, key, LD_WAIT_CONFIG); > ^~~~~~~~~~~~~~~~~~~~ > /stuff/linux/include/linux/spinlock.h:101:52: note: passing argument to parameter 'lock' here > extern void __raw_spin_lock_init(raw_spinlock_t *lock, const char *name, > ^ > 2 errors generated. > > This occurs because I have DEBUG_SPINLOCK enabled. I didn't check why, > but Andreas seems to have introduced that code - luckily he's already on > CC here :) > > With that disabled, there are dozens of warnings along the lines of: > /stuff/linux/rust/helpers/err.c:6:14: warning: symbol 'rust_helper_ERR_PTR' was not declared. Should it be static? > If those are okay for rust code, it would be rather helpful if the > warnings could be disabled - otherwise they should really be fixed. > > Following that, I got a build error: > > error[E0425]: cannot find function `__mutex_init` in crate `bindings` > --> /stuff/linux/rust/kernel/sync/lock/mutex.rs:104:28 > | > 104 | unsafe { bindings::__mutex_init(ptr, name, key) } > | ^^^^^^^^^^^^ help: a function with a similar name exists: `__mutex_rt_init` > | > ::: /stuff/brsdk/work/linux/rust/bindings/bindings_generated.rs:12907:5 > | > 12907 | / pub fn __mutex_rt_init( > 12908 | | lock: *mut mutex, > 12909 | | name: *const core::ffi::c_char, > 12910 | | key: *mut lock_class_key, > 12911 | | ); > | |_____- similarly named function `__mutex_rt_init` defined here > > error: aborting due to 1 previous error > > I stopped there, Space Marine 2 awaits. > > Hopefully I'll get to say hello next week, > Conor. Hi Conor, Do you have PREEMPT_RT enabled? Best, Gary
On Sat, Sep 14, 2024 at 05:30:37PM +0100, Gary Guo wrote: > On Fri, 13 Sep 2024 22:17:56 +0100 > Conor Dooley <conor@kernel.org> wrote: > > error[E0425]: cannot find function `__mutex_init` in crate `bindings` > > --> /stuff/linux/rust/kernel/sync/lock/mutex.rs:104:28 > > | > > 104 | unsafe { bindings::__mutex_init(ptr, name, key) } > > | ^^^^^^^^^^^^ help: a function with a similar name exists: `__mutex_rt_init` > > | > > ::: /stuff/brsdk/work/linux/rust/bindings/bindings_generated.rs:12907:5 > > | > > 12907 | / pub fn __mutex_rt_init( > > 12908 | | lock: *mut mutex, > > 12909 | | name: *const core::ffi::c_char, > > 12910 | | key: *mut lock_class_key, > > 12911 | | ); > > | |_____- similarly named function `__mutex_rt_init` defined here > > > > error: aborting due to 1 previous error > > > > Do you have PREEMPT_RT enabled? I do indeed.
On Sat, Sep 14, 2024 at 05:46:14PM +0100, Conor Dooley wrote: > On Sat, Sep 14, 2024 at 05:30:37PM +0100, Gary Guo wrote: > > On Fri, 13 Sep 2024 22:17:56 +0100 > > Conor Dooley <conor@kernel.org> wrote: > > > > error[E0425]: cannot find function `__mutex_init` in crate `bindings` > > > --> /stuff/linux/rust/kernel/sync/lock/mutex.rs:104:28 > > > | > > > 104 | unsafe { bindings::__mutex_init(ptr, name, key) } > > > | ^^^^^^^^^^^^ help: a function with a similar name exists: `__mutex_rt_init` > > > | > > > ::: /stuff/brsdk/work/linux/rust/bindings/bindings_generated.rs:12907:5 > > > | > > > 12907 | / pub fn __mutex_rt_init( > > > 12908 | | lock: *mut mutex, > > > 12909 | | name: *const core::ffi::c_char, > > > 12910 | | key: *mut lock_class_key, > > > 12911 | | ); > > > | |_____- similarly named function `__mutex_rt_init` defined here > > > > > > error: aborting due to 1 previous error > > > > > > > Do you have PREEMPT_RT enabled? > > I do indeed. Turned it off, only to find out my board farm is non-functional! Looks fine in QEMU however :)
Am 13.09.24 um 23:44 schrieb Alice Ryhl: > On Fri, Sep 13, 2024 at 11:18 PM Conor Dooley <conor@kernel.org> wrote: >> >> On Fri, Sep 13, 2024 at 12:08:20AM +0200, Miguel Ojeda wrote: >>> On Thu, Aug 29, 2024 at 10:23 AM Alice Ryhl <aliceryhl@google.com> wrote: >>>> >>>> Add all of the flags that are needed to support the shadow call stack >>>> (SCS) sanitizer with Rust, and updates Kconfig to allow only >>>> configurations that work. >>> >>> Applied to `rust-next` -- thanks everyone! >>> >>> Paul/Palmer/Albert/RISC-V: I think you were not Cc'd (at least in this >>> version?), so please shout if you have a problem with this. >> >> For some reason I deleted the series from my mailbox, must've been in >> dt-binding review mode and hit ctrl + d. I've been away and busy, so my >> apologies Alice for not trying this out sooner. >> It's sorta annoying to test rust + scs on riscv, cos you need (unless I >> am mistaken) llvm-19. llvm-18 + rust built fine, but has no SCS. >> >> llvm-19 + rust failed to build for me riscv, producing: >> >> In file included from /stuff/linux/rust/helpers/helpers.c:22: >> /stuff/linux/rust/helpers/spinlock.c:10:23: error: call to undeclared function 'spinlock_check'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] >> __raw_spin_lock_init(spinlock_check(lock), name, key, LD_WAIT_CONFIG); >> ^ >> /stuff/linux/rust/helpers/spinlock.c:10:23: error: incompatible integer to pointer conversion passing 'int' to parameter of type 'raw_spinlock_t *' (aka 'struct raw_spinlock *') [-Wint-conversion] >> __raw_spin_lock_init(spinlock_check(lock), name, key, LD_WAIT_CONFIG); >> ^~~~~~~~~~~~~~~~~~~~ >> /stuff/linux/include/linux/spinlock.h:101:52: note: passing argument to parameter 'lock' here >> extern void __raw_spin_lock_init(raw_spinlock_t *lock, const char *name, >> ^ >> 2 errors generated. >> >> This occurs because I have DEBUG_SPINLOCK enabled. I didn't check why, >> but Andreas seems to have introduced that code - luckily he's already on >> CC here :) >> >> With that disabled, there are dozens of warnings along the lines of: >> /stuff/linux/rust/helpers/err.c:6:14: warning: symbol 'rust_helper_ERR_PTR' was not declared. Should it be static? >> If those are okay for rust code, it would be rather helpful if the >> warnings could be disabled - otherwise they should really be fixed. >> >> Following that, I got a build error: >> >> error[E0425]: cannot find function `__mutex_init` in crate `bindings` >> --> /stuff/linux/rust/kernel/sync/lock/mutex.rs:104:28 >> | >> 104 | unsafe { bindings::__mutex_init(ptr, name, key) } >> | ^^^^^^^^^^^^ help: a function with a similar name exists: `__mutex_rt_init` >> | >> ::: /stuff/brsdk/work/linux/rust/bindings/bindings_generated.rs:12907:5 >> | >> 12907 | / pub fn __mutex_rt_init( >> 12908 | | lock: *mut mutex, >> 12909 | | name: *const core::ffi::c_char, >> 12910 | | key: *mut lock_class_key, >> 12911 | | ); >> | |_____- similarly named function `__mutex_rt_init` defined here >> >> error: aborting due to 1 previous error > > This looks like an unrelated problem to me. Yes, it is unrelated to this change. It is PREEMPT_RT usage related. I think we could add something like #ifdef CONFIG_PREEMPT_RT void rust_helper___mutex_init(struct mutex *mutex, const char *name, struct lock_class_key *key) { return __mutex_init(mutex, name, key); } #endif to helpers to fix https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/rust/kernel/sync/lock/mutex.rs?&id=6d20d629c6d8575be98eeebe49a16fb2d7b32350 ? Explanation: Looking at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/mutex.h?#n52 we have (simplified) #ifndef CONFIG_PREEMPT_RT extern void __mutex_init(struct mutex *lock, const char *name, struct lock_class_key *key); #else #define __mutex_init(mutex, name, key) \ do { \ rt_mutex_base_init(&(mutex)->rtmutex); \ __mutex_rt_init((mutex), name, key); \ } while (0) #endif So in the CONFIG_PREEMPT_RT case bindgen doesn't resolve the macro what could be fixed by adding a helper. Dirk > This patch only changes > the rustc flags, but these errors have to do with the Rust > helpers/bindings, which get generated before the rustc flags are used > at all. Most likely, there is a problem under the particular > configuration you are using. Were you able to reproduce these errors > without this patch? > >> I stopped there, Space Marine 2 awaits. >> >> Hopefully I'll get to say hello next week, >> Conor. > > Thanks for taking a look, and see you at Plumbers! > > Alice >
On Sun, 15 Sep 2024 09:32:44 +0200 Dirk Behme <dirk.behme@gmail.com> wrote: > Yes, it is unrelated to this change. It is PREEMPT_RT usage related. I > think we could add something like > > #ifdef CONFIG_PREEMPT_RT > void rust_helper___mutex_init(struct mutex *mutex, const char *name, > struct lock_class_key *key) > { > return __mutex_init(mutex, name, key); > } > #endif There's no need to use `ifdef` here (we don't want to try replicate all ifdefs). Simply add a helper is sufficient. We have logic in rust/bindings/lib.rs to prefer externed function to helpers if an externed function exist. Best, Gary > > to helpers to fix > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/rust/kernel/sync/lock/mutex.rs?&id=6d20d629c6d8575be98eeebe49a16fb2d7b32350 > > ? > > Explanation: Looking at > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/mutex.h?#n52 > > we have (simplified) > > #ifndef CONFIG_PREEMPT_RT > extern void __mutex_init(struct mutex *lock, const char *name, > struct lock_class_key *key); > #else > #define __mutex_init(mutex, name, key) \ > do { \ > rt_mutex_base_init(&(mutex)->rtmutex); \ > __mutex_rt_init((mutex), name, key); \ > } while (0) > #endif > > So in the CONFIG_PREEMPT_RT case bindgen doesn't resolve the macro > what could be fixed by adding a helper. > > Dirk
On Sun, Sep 15, 2024 at 12:15 AM Conor Dooley <conor@kernel.org> wrote: > > Turned it off, only to find out my board farm is non-functional! Looks > fine in QEMU however :) Thanks for checking that -- I have kept the patch in `rust-next` applied since it is unrelated. Cheers, Miguel
diff --git a/Makefile b/Makefile index 68ebd6d6b444..2b384a72ff39 100644 --- a/Makefile +++ b/Makefile @@ -927,6 +927,7 @@ ifdef CONFIG_SHADOW_CALL_STACK ifndef CONFIG_DYNAMIC_SCS CC_FLAGS_SCS := -fsanitize=shadow-call-stack KBUILD_CFLAGS += $(CC_FLAGS_SCS) +KBUILD_RUSTFLAGS += -Zsanitizer=shadow-call-stack endif export CC_FLAGS_SCS endif diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index a2f8ff354ca6..827497df6fa3 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -231,7 +231,7 @@ config ARM64 select HAVE_FUNCTION_ARG_ACCESS_API select MMU_GATHER_RCU_TABLE_FREE select HAVE_RSEQ - select HAVE_RUST if CPU_LITTLE_ENDIAN + select HAVE_RUST if RUSTC_SUPPORTS_ARM64 select HAVE_STACKPROTECTOR select HAVE_SYSCALL_TRACEPOINTS select HAVE_KPROBES @@ -265,6 +265,18 @@ config ARM64 help ARM 64-bit (AArch64) Linux support. +config RUSTC_SUPPORTS_ARM64 + def_bool y + depends on CPU_LITTLE_ENDIAN + # Shadow call stack is only supported on certain rustc versions. + # + # When using the UNWIND_PATCH_PAC_INTO_SCS option, rustc version 1.80+ is + # required due to use of the -Zfixed-x18 flag. + # + # Otherwise, rustc version 1.82+ is required due to use of the + # -Zsanitizer=shadow-call-stack flag. + depends on !SHADOW_CALL_STACK || RUSTC_VERSION >= 108200 || RUSTC_VERSION >= 108000 && UNWIND_PATCH_PAC_INTO_SCS + config CLANG_SUPPORTS_DYNAMIC_FTRACE_WITH_ARGS def_bool CC_IS_CLANG # https://github.com/ClangBuiltLinux/linux/issues/1507 diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile index f6bc3da1ef11..b058c4803efb 100644 --- a/arch/arm64/Makefile +++ b/arch/arm64/Makefile @@ -57,9 +57,11 @@ KBUILD_AFLAGS += $(call cc-option,-mabi=lp64) ifneq ($(CONFIG_UNWIND_TABLES),y) KBUILD_CFLAGS += -fno-asynchronous-unwind-tables -fno-unwind-tables KBUILD_AFLAGS += -fno-asynchronous-unwind-tables -fno-unwind-tables +KBUILD_RUSTFLAGS += -Cforce-unwind-tables=n else KBUILD_CFLAGS += -fasynchronous-unwind-tables KBUILD_AFLAGS += -fasynchronous-unwind-tables +KBUILD_RUSTFLAGS += -Cforce-unwind-tables=y -Zuse-sync-unwind=n endif ifeq ($(CONFIG_STACKPROTECTOR_PER_TASK),y) @@ -114,6 +116,7 @@ endif ifeq ($(CONFIG_SHADOW_CALL_STACK), y) KBUILD_CFLAGS += -ffixed-x18 +KBUILD_RUSTFLAGS += -Zfixed-x18 endif ifeq ($(CONFIG_CPU_BIG_ENDIAN), y) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 0f3cd7c3a436..7ffdb3bdfd3f 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -172,7 +172,7 @@ config RISCV select HAVE_REGS_AND_STACK_ACCESS_API select HAVE_RETHOOK if !XIP_KERNEL select HAVE_RSEQ - select HAVE_RUST if 64BIT + select HAVE_RUST if RUSTC_SUPPORTS_RISCV select HAVE_SAMPLE_FTRACE_DIRECT select HAVE_SAMPLE_FTRACE_DIRECT_MULTI select HAVE_STACKPROTECTOR @@ -202,6 +202,13 @@ config RISCV select UACCESS_MEMCPY if !MMU select ZONE_DMA32 if 64BIT +config RUSTC_SUPPORTS_RISCV + def_bool y + depends on 64BIT + # Shadow call stack requires rustc version 1.82+ due to use of the + # -Zsanitizer=shadow-call-stack flag. + depends on !SHADOW_CALL_STACK || RUSTC_VERSION >= 108200 + config CLANG_SUPPORTS_DYNAMIC_FTRACE def_bool CC_IS_CLANG # https://github.com/ClangBuiltLinux/linux/issues/1817 diff --git a/init/Kconfig b/init/Kconfig index 38c1cfcce821..2d3d5caee1e0 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1909,7 +1909,6 @@ config RUST depends on !MODVERSIONS depends on !GCC_PLUGIN_RANDSTRUCT depends on !RANDSTRUCT - depends on !SHADOW_CALL_STACK depends on !DEBUG_INFO_BTF || PAHOLE_HAS_LANG_EXCLUDE help Enables Rust support in the kernel.