diff mbox series

[v7] rust: support for shadow call stack sanitizer

Message ID 20240829-shadow-call-stack-v7-1-2f62a4432abf@google.com (mailing list archive)
State New
Headers show
Series [v7] rust: support for shadow call stack sanitizer | expand

Commit Message

Alice Ryhl Aug. 29, 2024, 8:22 a.m. UTC
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.

The -Zfixed-x18 flag is required to use SCS on arm64, and requires rustc
version 1.80.0 or greater. This restriction is reflected in Kconfig.

When CONFIG_DYNAMIC_SCS is enabled, the build will be configured to
include unwind tables in the build artifacts. Dynamic SCS uses the
unwind tables at boot to find all places that need to be patched. The
-Cforce-unwind-tables=y flag ensures that unwind tables are available
for Rust code.

In non-dynamic mode, the -Zsanitizer=shadow-call-stack flag is what
enables the SCS sanitizer. Using this flag requires rustc version 1.82.0
or greater on the targets used by Rust in the kernel. This restriction
is reflected in Kconfig.

It is possible to avoid the requirement of rustc 1.80.0 by using
-Ctarget-feature=+reserve-x18 instead of -Zfixed-x18. However, this flag
emits a warning during the build, so this patch does not add support for
using it and instead requires 1.80.0 or greater.

The dependency is placed on `select HAVE_RUST` to avoid a situation
where enabling Rust silently turns off the sanitizer. Instead, turning
on the sanitizer results in Rust being disabled. We generally do not
want changes to CONFIG_RUST to result in any mitigations being changed
or turned off.

At the time of writing, rustc 1.82.0 only exists via the nightly release
channel. There is a chance that the -Zsanitizer=shadow-call-stack flag
will end up needing 1.83.0 instead, but I think it is small.

Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Kees Cook <kees@kernel.org>
Acked-by: Will Deacon <will@kernel.org>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
This patch depends on RUSTC_VERSION:
https://lore.kernel.org/rust-for-linux/20240808221138.873750-1-ojeda@kernel.org/
---
Changes in v7:
- Add comment to `config RUSTC_SUPPORTS_[ARM64|RISCV]`
- Pick up tags from reviewers.
- Link to v6: https://lore.kernel.org/r/20240826-shadow-call-stack-v6-1-495a7e3eb0ef@google.com

Changes in v6:
- Move Kconfig requirements into arch/*/Kconfig.
- List non-dynamic SCS as supported on 1.82. This reflects newly added
  things in rustc.
- Link to v5: https://lore.kernel.org/r/20240806-shadow-call-stack-v5-1-26dccb829154@google.com

Changes in v5:
- Rebase series on v6.11-rc2.
- The first patch is no longer included as it was merged in v6.11-rc2.
- The commit message is rewritten from scratch.
- Link to v4: https://lore.kernel.org/r/20240729-shadow-call-stack-v4-0-2a664b082ea4@google.com

Changes in v4:
- Move `depends on` to CONFIG_RUST.
- Rewrite commit messages to include more context.
- Link to v3: https://lore.kernel.org/r/20240704-shadow-call-stack-v3-0-d11c7a6ebe30@google.com

Changes in v3:
- Use -Zfixed-x18.
- Add logic to reject unsupported rustc versions.
- Also include a fix to be backported.
- Link to v2: https://lore.kernel.org/rust-for-linux/20240305-shadow-call-stack-v2-1-c7b4a3f4d616@google.com/

Changes in v2:
- Add -Cforce-unwind-tables flag.
- Link to v1: https://lore.kernel.org/rust-for-linux/20240304-shadow-call-stack-v1-1-f055eaf40a2c@google.com/
---
 Makefile            |  1 +
 arch/arm64/Kconfig  | 14 +++++++++++++-
 arch/arm64/Makefile |  3 +++
 arch/riscv/Kconfig  |  9 ++++++++-
 init/Kconfig        |  1 -
 5 files changed, 25 insertions(+), 3 deletions(-)


---
base-commit: 12f2c9d5c2bef419700514ca627e3a5c27f380d9
change-id: 20240304-shadow-call-stack-9c197a4361d9

Best regards,

Comments

Miguel Ojeda Sept. 12, 2024, 10:08 p.m. UTC | #1
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
Conor Dooley Sept. 13, 2024, 9:17 p.m. UTC | #2
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.
Alice Ryhl Sept. 13, 2024, 9:44 p.m. UTC | #3
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
Conor Dooley Sept. 13, 2024, 9:47 p.m. UTC | #4
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.
Gary Guo Sept. 14, 2024, 4:30 p.m. UTC | #5
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
Conor Dooley Sept. 14, 2024, 4:46 p.m. UTC | #6
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.
Conor Dooley Sept. 14, 2024, 10:15 p.m. UTC | #7
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 :)
Dirk Behme Sept. 15, 2024, 7:32 a.m. UTC | #8
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
>
Gary Guo Sept. 15, 2024, 11:36 a.m. UTC | #9
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
Miguel Ojeda Sept. 15, 2024, 7:15 p.m. UTC | #10
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 mbox series

Patch

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.