Add flags to support the shadow call stack sanitizer, both in the
dynamic and non-dynamic modes.
Right now, the compiler will emit the warning "unknown feature specified
for `-Ctarget-feature`: `reserve-x18`". However, the compiler still
passes it to the codegen backend, so the flag will work just fine. Once
rustc starts recognizing the flag (or provides another way to enable the
feature), it will stop emitting this warning. See [1] for the relevant
issue.
Currently, the compiler thinks that the aarch64-unknown-none target
doesn't support -Zsanitizer=shadow-call-stack, so the build will fail if
you enable shadow call stack in non-dynamic mode. However, I still think
it is reasonable to add the flag now, as it will at least fail the build
when using an invalid configuration, until the Rust compiler is fixed to
list -Zsanitizer=shadow-call-stack as supported for the target. See [2]
for the feature request to add this.
I have tested this change with Rust Binder on an Android device using
CONFIG_DYNAMIC_SCS. Without the -Ctarget-feature=+reserve-x18 flag, the
phone crashes immediately on boot, and with the flag, the phone appears
to work normally.
This contains a TODO to add the -Zuse-sync-unwind=n flag. The flag
defaults to n, so it isn't a problem today, but the flag is unstable, so
the default could change in a future compiler release.
Link: https://github.com/rust-lang/rust/issues/121970 [1]
Link: https://github.com/rust-lang/rust/issues/121972 [2]
Signed-off-by: Alice Ryhl <[email protected]>
---
This patch raises the question of whether we should change the Rust
aarch64 support to use a custom target.json specification. If we do
that, then we can fix both the warning for dynamic SCS and the
build-failure for non-dynamic SCS without waiting for a new version of
rustc with the mentioned issues fixed.
---
Changes in v2:
- Add -Cforce-unwind-tables flag.
- Link to v1: https://lore.kernel.org/r/[email protected]
---
Makefile | 1 +
arch/arm64/Makefile | 4 ++++
2 files changed, 5 insertions(+)
diff --git a/Makefile b/Makefile
index 0e36eff14608..345066643a76 100644
--- a/Makefile
+++ b/Makefile
@@ -936,6 +936,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/Makefile b/arch/arm64/Makefile
index a88cdf910687..9bd5522c18e9 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -48,9 +48,12 @@ 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
+# TODO: Pass -Zuse-sync-unwind=n once we upgrade to Rust 1.77.0
+KBUILD_RUSTFLAGS += -Cforce-unwind-tables=y
endif
ifeq ($(CONFIG_STACKPROTECTOR_PER_TASK),y)
@@ -103,6 +106,7 @@ endif
ifeq ($(CONFIG_SHADOW_CALL_STACK), y)
KBUILD_CFLAGS += -ffixed-x18
+KBUILD_RUSTFLAGS += -Ctarget-feature=+reserve-x18
endif
ifeq ($(CONFIG_CPU_BIG_ENDIAN), y)
---
base-commit: 90d35da658da8cff0d4ecbb5113f5fac9d00eb72
change-id: 20240304-shadow-call-stack-9c197a4361d9
Best regards,
--
Alice Ryhl <[email protected]>
On Tue, Mar 5, 2024 at 12:58 PM Alice Ryhl <[email protected]> wrote:
>
> Add flags to support the shadow call stack sanitizer, both in the
> dynamic and non-dynamic modes.
>
> Right now, the compiler will emit the warning "unknown feature specified
> for `-Ctarget-feature`: `reserve-x18`". However, the compiler still
> passes it to the codegen backend, so the flag will work just fine. Once
> rustc starts recognizing the flag (or provides another way to enable the
> feature), it will stop emitting this warning. See [1] for the relevant
> issue.
>
> Currently, the compiler thinks that the aarch64-unknown-none target
> doesn't support -Zsanitizer=shadow-call-stack, so the build will fail if
> you enable shadow call stack in non-dynamic mode. However, I still think
> it is reasonable to add the flag now, as it will at least fail the build
> when using an invalid configuration, until the Rust compiler is fixed to
> list -Zsanitizer=shadow-call-stack as supported for the target. See [2]
> for the feature request to add this.
>
> I have tested this change with Rust Binder on an Android device using
> CONFIG_DYNAMIC_SCS. Without the -Ctarget-feature=+reserve-x18 flag, the
> phone crashes immediately on boot, and with the flag, the phone appears
> to work normally.
>
> This contains a TODO to add the -Zuse-sync-unwind=n flag. The flag
> defaults to n, so it isn't a problem today, but the flag is unstable, so
> the default could change in a future compiler release.
>
> Link: https://github.com/rust-lang/rust/issues/121970 [1]
> Link: https://github.com/rust-lang/rust/issues/121972 [2]
> Signed-off-by: Alice Ryhl <[email protected]>
> ---
> This patch raises the question of whether we should change the Rust
> aarch64 support to use a custom target.json specification. If we do
> that, then we can fix both the warning for dynamic SCS and the
> build-failure for non-dynamic SCS without waiting for a new version of
> rustc with the mentioned issues fixed.
If the arm64 maintainers are OK with the warning being triggered in that case:
Acked-by: Miguel Ojeda <[email protected]>
Otherwise partially reverting to the `target.json` approach sounds good too.
I added the `-Zuse-sync-unwind=n` to the list at
https://github.com/Rust-for-Linux/linux/issues/2. Given the default is
what we want, I have put it in the "Good to have" section.
Cheers,
Miguel
> Add flags to support the shadow call stack sanitizer, both in the
> dynamic and non-dynamic modes.
>
> Right now, the compiler will emit the warning "unknown feature specified
> for `-Ctarget-feature`: `reserve-x18`". However, the compiler still
> passes it to the codegen backend, so the flag will work just fine. Once
> rustc starts recognizing the flag (or provides another way to enable the
> feature), it will stop emitting this warning. See [1] for the relevant
> issue.
>
> Currently, the compiler thinks that the aarch64-unknown-none target
> doesn't support -Zsanitizer=shadow-call-stack, so the build will fail if
> you enable shadow call stack in non-dynamic mode. However, I still think
> it is reasonable to add the flag now, as it will at least fail the build
> when using an invalid configuration, until the Rust compiler is fixed to
> list -Zsanitizer=shadow-call-stack as supported for the target. See [2]
> for the feature request to add this.
>
> I have tested this change with Rust Binder on an Android device using
> CONFIG_DYNAMIC_SCS. Without the -Ctarget-feature=+reserve-x18 flag, the
> phone crashes immediately on boot, and with the flag, the phone appears
> to work normally.
>
> This contains a TODO to add the -Zuse-sync-unwind=n flag. The flag
> defaults to n, so it isn't a problem today, but the flag is unstable, so
> the default could change in a future compiler release.
>
> Link: https://github.com/rust-lang/rust/issues/121970 [1]
> Link: https://github.com/rust-lang/rust/issues/121972 [2]
> Signed-off-by: Alice Ryhl <[email protected]>
> ---
> This patch raises the question of whether we should change the Rust
> aarch64 support to use a custom target.json specification. If we do
> that, then we can fix both the warning for dynamic SCS and the
> build-failure for non-dynamic SCS without waiting for a new version of
> rustc with the mentioned issues fixed.
> ---
> Changes in v2:
> - Add -Cforce-unwind-tables flag.
> - Link to v1: https://lore.kernel.org/r/[email protected]
> ---
>
> Makefile | 1 +
> arch/arm64/Makefile | 4 ++++
> 2 files changed, 5 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index 0e36eff14608..345066643a76 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -936,6 +936,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/Makefile b/arch/arm64/Makefile
> index a88cdf910687..9bd5522c18e9 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -48,9 +48,12 @@ 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
> +# TODO: Pass -Zuse-sync-unwind=n once we upgrade to Rust 1.77.0
> +KBUILD_RUSTFLAGS += -Cforce-unwind-tables=y
> endif
>
That's the setup I used for my previous testing at [1], offering:
Tested-by: Valentin Obst <[email protected]>
Reviewed-by: Valentin Obst <[email protected]>
- Best Valentin
Link: https://lore.kernel.org/all/[email protected]/ [1]
> ifeq ($(CONFIG_STACKPROTECTOR_PER_TASK),y)
> @@ -103,6 +106,7 @@ endif
>
> ifeq ($(CONFIG_SHADOW_CALL_STACK), y)
> KBUILD_CFLAGS += -ffixed-x18
> +KBUILD_RUSTFLAGS += -Ctarget-feature=+reserve-x18
> endif
>
> ifeq ($(CONFIG_CPU_BIG_ENDIAN), y)
On Tue, Mar 05, 2024 at 11:58:45AM +0000, Alice Ryhl wrote:
> Add flags to support the shadow call stack sanitizer, both in the
> dynamic and non-dynamic modes.
>
> Right now, the compiler will emit the warning "unknown feature specified
> for `-Ctarget-feature`: `reserve-x18`". However, the compiler still
> passes it to the codegen backend, so the flag will work just fine. Once
> rustc starts recognizing the flag (or provides another way to enable the
> feature), it will stop emitting this warning. See [1] for the relevant
> issue.
>
> Currently, the compiler thinks that the aarch64-unknown-none target
> doesn't support -Zsanitizer=shadow-call-stack, so the build will fail if
> you enable shadow call stack in non-dynamic mode. However, I still think
> it is reasonable to add the flag now, as it will at least fail the build
> when using an invalid configuration, until the Rust compiler is fixed to
> list -Zsanitizer=shadow-call-stack as supported for the target. See [2]
> for the feature request to add this.
>
> I have tested this change with Rust Binder on an Android device using
> CONFIG_DYNAMIC_SCS. Without the -Ctarget-feature=+reserve-x18 flag, the
> phone crashes immediately on boot, and with the flag, the phone appears
> to work normally.
>
> This contains a TODO to add the -Zuse-sync-unwind=n flag. The flag
> defaults to n, so it isn't a problem today, but the flag is unstable, so
> the default could change in a future compiler release.
>
> Link: https://github.com/rust-lang/rust/issues/121970 [1]
> Link: https://github.com/rust-lang/rust/issues/121972 [2]
> Signed-off-by: Alice Ryhl <[email protected]>
> ---
> This patch raises the question of whether we should change the Rust
> aarch64 support to use a custom target.json specification. If we do
> that, then we can fix both the warning for dynamic SCS and the
> build-failure for non-dynamic SCS without waiting for a new version of
> rustc with the mentioned issues fixed.
> ---
> Changes in v2:
> - Add -Cforce-unwind-tables flag.
> - Link to v1: https://lore.kernel.org/r/[email protected]
Reviewed-by: Sami Tolvanen <[email protected]>
Sami
On Tue, Mar 05, 2024 at 01:14:19PM +0100, Miguel Ojeda wrote:
> On Tue, Mar 5, 2024 at 12:58 PM Alice Ryhl <[email protected]> wrote:
> >
> > Add flags to support the shadow call stack sanitizer, both in the
> > dynamic and non-dynamic modes.
> >
> > Right now, the compiler will emit the warning "unknown feature specified
> > for `-Ctarget-feature`: `reserve-x18`". However, the compiler still
> > passes it to the codegen backend, so the flag will work just fine. Once
> > rustc starts recognizing the flag (or provides another way to enable the
> > feature), it will stop emitting this warning. See [1] for the relevant
> > issue.
> >
> > Currently, the compiler thinks that the aarch64-unknown-none target
> > doesn't support -Zsanitizer=shadow-call-stack, so the build will fail if
> > you enable shadow call stack in non-dynamic mode. However, I still think
> > it is reasonable to add the flag now, as it will at least fail the build
> > when using an invalid configuration, until the Rust compiler is fixed to
> > list -Zsanitizer=shadow-call-stack as supported for the target. See [2]
> > for the feature request to add this.
> >
> > I have tested this change with Rust Binder on an Android device using
> > CONFIG_DYNAMIC_SCS. Without the -Ctarget-feature=+reserve-x18 flag, the
> > phone crashes immediately on boot, and with the flag, the phone appears
> > to work normally.
> >
> > This contains a TODO to add the -Zuse-sync-unwind=n flag. The flag
> > defaults to n, so it isn't a problem today, but the flag is unstable, so
> > the default could change in a future compiler release.
> >
> > Link: https://github.com/rust-lang/rust/issues/121970 [1]
> > Link: https://github.com/rust-lang/rust/issues/121972 [2]
> > Signed-off-by: Alice Ryhl <[email protected]>
> > ---
> > This patch raises the question of whether we should change the Rust
> > aarch64 support to use a custom target.json specification. If we do
> > that, then we can fix both the warning for dynamic SCS and the
> > build-failure for non-dynamic SCS without waiting for a new version of
> > rustc with the mentioned issues fixed.
>
> If the arm64 maintainers are OK with the warning being triggered in that case:
Sorry, I meant to reply on this at the time...
> Acked-by: Miguel Ojeda <[email protected]>
>
> Otherwise partially reverting to the `target.json` approach sounds good too.
>
> I added the `-Zuse-sync-unwind=n` to the list at
> https://github.com/Rust-for-Linux/linux/issues/2. Given the default is
> what we want, I have put it in the "Good to have" section.
I think we have time to do this properly, like we did for the clang
enablement a few years ago. In hindsight, avoiding hacks for the early
toolchains back then was a really good idea because it meant we could
rely on a solid baseline set of compiler features from the start.
So, please can we fix this in rustc and just have SCS dependent on that?
Cheers,
Will
On Tue, Apr 9, 2024 at 12:31 PM Will Deacon <[email protected]> wrote:
>
> I think we have time to do this properly, like we did for the clang
> enablement a few years ago. In hindsight, avoiding hacks for the early
> toolchains back then was a really good idea because it meant we could
> rely on a solid baseline set of compiler features from the start.
Yeah, it sounds fair, thanks!
After the warning is fixed (i.e. `-Zfixed-x18` or similar is
implemented etc.), I would recommend adding support to the kernel for
the `-Z` (unstable) flags, similar to this patch, in order to test
them easily and getting `rustc` to stabilize them. Then the only
change required should be a name change to `-C` or similar.
Cheers,
Miguel
Will Deacon <[email protected]> wrote:
> On Tue, Mar 05, 2024 at 01:14:19PM +0100, Miguel Ojeda wrote:
>> Otherwise partially reverting to the `target.json` approach sounds good too.
>>
>> I added the `-Zuse-sync-unwind=n` to the list at
>> https://github.com/Rust-for-Linux/linux/issues/2. Given the default is
>> what we want, I have put it in the "Good to have" section.
>
> I think we have time to do this properly, like we did for the clang
> enablement a few years ago. In hindsight, avoiding hacks for the early
> toolchains back then was a really good idea because it meant we could
> rely on a solid baseline set of compiler features from the start.
>
> So, please can we fix this in rustc and just have SCS dependent on that?
Hi Will,
Just to keep you in the loop, I've posted a PR to make rustc recognize
the reserve-x18 target feature, so that the -Ctarget-feature=+reserve-x18
flag stops emitting a warning.
This should be sufficient for adding support for CONFIG_DYNAMIC_SCS.
You can find it here:
https://github.com/rust-lang/rust/pull/124323
As for non-dynamic SCS, I plan to tackle that after the PR is merged.
See the "Future possibilities" section in the linked PR for more info on
that.
Alice