* Re: [PATCH v5] rust: support for shadow call stack sanitizer
2024-08-06 10:01 [PATCH v5] rust: support for shadow call stack sanitizer Alice Ryhl
@ 2024-08-06 19:37 ` Kees Cook
2024-08-06 20:27 ` Sami Tolvanen
2024-08-20 14:35 ` Will Deacon
2 siblings, 0 replies; 11+ messages in thread
From: Kees Cook @ 2024-08-06 19:37 UTC (permalink / raw)
To: Alice Ryhl, Ard Biesheuvel
Cc: Catalin Marinas, Will Deacon, Jamie Cunliffe, Sami Tolvanen,
Nathan Chancellor, Conor Dooley, Masahiro Yamada, Nicolas Schier,
Marc Zyngier, Mark Rutland, Mark Brown, Nick Desaulniers,
Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Valentin Obst, linux-kbuild, linux-kernel, linux-arm-kernel,
rust-for-linux
On Tue, Aug 06, 2024 at 10:01:44AM +0000, Alice Ryhl wrote:
> This patch adds all of the flags that are needed to support the shadow
> call stack (SCS) sanitizer with Rust, and updates Kconfig to allow
> 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.
>
> At the time of writing, all released rustc versions up to and including
> 1.81 incorrectly think that the Rust targets aarch64-unknown-none and
> riscv64-unknown-none-elf don't support -Zsanitizer=shadow-call-stack, so
> the build will fail if you enable shadow call stack in non-dynamic mode.
> See [1] for the relevant feature request. To avoid this compilation
> failure, Kconfig is set up to reject such configurations.
>
> Note that because these configurations are rejected, this patch only
> allows SCS to be used with arm64 and not on riscv. However, once [1] is
> implemented, I will submit a follow-up patch that allows configurations
> without UNWIND_PATCH_PAC_INTO_SCS on sufficiently new compilers. That
> patch will implicitly allow SCS to be enabled on riscv, but this is okay
> because unlike arm64, riscv does not need any flags for rustc beyond
> -Zsanitizer=shadow-call-stack.
>
> 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 `depends on` clause is placed on `config 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.
>
> Link: https://github.com/rust-lang/rust/issues/121972 [1]
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
I'd like to make sure Ard is happy with this, but from what I can see it
looks correct. Thanks!
Reviewed-by: Kees Cook <kees@kernel.org>
--
Kees Cook
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v5] rust: support for shadow call stack sanitizer
2024-08-06 10:01 [PATCH v5] rust: support for shadow call stack sanitizer Alice Ryhl
2024-08-06 19:37 ` Kees Cook
@ 2024-08-06 20:27 ` Sami Tolvanen
2024-08-20 14:35 ` Will Deacon
2 siblings, 0 replies; 11+ messages in thread
From: Sami Tolvanen @ 2024-08-06 20:27 UTC (permalink / raw)
To: Alice Ryhl
Cc: Catalin Marinas, Will Deacon, Jamie Cunliffe, Nathan Chancellor,
Conor Dooley, Masahiro Yamada, Nicolas Schier, Ard Biesheuvel,
Marc Zyngier, Mark Rutland, Mark Brown, Nick Desaulniers,
Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Valentin Obst, linux-kbuild, linux-kernel, linux-arm-kernel,
rust-for-linux, Kees Cook
On Tue, Aug 06, 2024 at 10:01:44AM +0000, Alice Ryhl wrote:
> This patch adds all of the flags that are needed to support the shadow
> call stack (SCS) sanitizer with Rust, and updates Kconfig to allow
> 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.
>
> At the time of writing, all released rustc versions up to and including
> 1.81 incorrectly think that the Rust targets aarch64-unknown-none and
> riscv64-unknown-none-elf don't support -Zsanitizer=shadow-call-stack, so
> the build will fail if you enable shadow call stack in non-dynamic mode.
> See [1] for the relevant feature request. To avoid this compilation
> failure, Kconfig is set up to reject such configurations.
>
> Note that because these configurations are rejected, this patch only
> allows SCS to be used with arm64 and not on riscv. However, once [1] is
> implemented, I will submit a follow-up patch that allows configurations
> without UNWIND_PATCH_PAC_INTO_SCS on sufficiently new compilers. That
> patch will implicitly allow SCS to be enabled on riscv, but this is okay
> because unlike arm64, riscv does not need any flags for rustc beyond
> -Zsanitizer=shadow-call-stack.
>
> 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 `depends on` clause is placed on `config 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.
>
> Link: https://github.com/rust-lang/rust/issues/121972 [1]
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Looks good to me, thanks!
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Sami
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v5] rust: support for shadow call stack sanitizer
2024-08-06 10:01 [PATCH v5] rust: support for shadow call stack sanitizer Alice Ryhl
2024-08-06 19:37 ` Kees Cook
2024-08-06 20:27 ` Sami Tolvanen
@ 2024-08-20 14:35 ` Will Deacon
2024-08-20 15:13 ` Alice Ryhl
2 siblings, 1 reply; 11+ messages in thread
From: Will Deacon @ 2024-08-20 14:35 UTC (permalink / raw)
To: Alice Ryhl
Cc: Catalin Marinas, Jamie Cunliffe, Sami Tolvanen, Nathan Chancellor,
Conor Dooley, Masahiro Yamada, Nicolas Schier, Ard Biesheuvel,
Marc Zyngier, Mark Rutland, Mark Brown, Nick Desaulniers,
Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Valentin Obst, linux-kbuild, linux-kernel, linux-arm-kernel,
rust-for-linux, Kees Cook
On Tue, Aug 06, 2024 at 10:01:44AM +0000, Alice Ryhl wrote:
> This patch adds all of the flags that are needed to support the shadow
> call stack (SCS) sanitizer with Rust, and updates Kconfig to allow
> configurations that work.
Minor nit, but some folks have allergic reactions to "This patch".
See:
https://docs.kernel.org/process/submitting-patches.html#describe-your-changes
I think the commit message is much better now, though, so thank you for
adding so much more detail for v5. If you end up respinning anyway, you
could move this all to the imperative.
> Makefile | 1 +
> arch/arm64/Makefile | 3 +++
> init/Kconfig | 2 +-
> 3 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 44c02a6f60a1..eb01a26d8354 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/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/init/Kconfig b/init/Kconfig
> index fe76c5d0a72e..d857f6f90885 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1909,7 +1909,7 @@ config RUST
> depends on !MODVERSIONS
> depends on !GCC_PLUGINS
> depends on !RANDSTRUCT
> - depends on !SHADOW_CALL_STACK
> + depends on !SHADOW_CALL_STACK || RUSTC_VERSION >= 108000 && UNWIND_PATCH_PAC_INTO_SCS
Sorry, I didn't spot this in v4, but since UNWIND_PATCH_PAC_INTO_SCS is
specific to arm64 and the only other architecture selecting
ARCH_SUPPORTS_SHADOW_CALL_STACK is riscv, I can't help but feel it would
be cleaner to move this logic into the arch code selecting HAVE_RUST.
That is, it's up to the architecture to make sure that it has whatever
it needs for SCS to work with Rust if it claims to support Rust.
What do you think?
Will
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v5] rust: support for shadow call stack sanitizer
2024-08-20 14:35 ` Will Deacon
@ 2024-08-20 15:13 ` Alice Ryhl
2024-08-23 12:24 ` Will Deacon
0 siblings, 1 reply; 11+ messages in thread
From: Alice Ryhl @ 2024-08-20 15:13 UTC (permalink / raw)
To: Will Deacon
Cc: Catalin Marinas, Jamie Cunliffe, Sami Tolvanen, Nathan Chancellor,
Conor Dooley, Masahiro Yamada, Nicolas Schier, Ard Biesheuvel,
Marc Zyngier, Mark Rutland, Mark Brown, Nick Desaulniers,
Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Valentin Obst, linux-kbuild, linux-kernel, linux-arm-kernel,
rust-for-linux, Kees Cook
On Tue, Aug 20, 2024 at 4:35 PM Will Deacon <will@kernel.org> wrote:
>
> On Tue, Aug 06, 2024 at 10:01:44AM +0000, Alice Ryhl wrote:
> > This patch adds all of the flags that are needed to support the shadow
> > call stack (SCS) sanitizer with Rust, and updates Kconfig to allow
> > configurations that work.
>
> Minor nit, but some folks have allergic reactions to "This patch".
> See:
>
> https://docs.kernel.org/process/submitting-patches.html#describe-your-changes
>
> I think the commit message is much better now, though, so thank you for
> adding so much more detail for v5. If you end up respinning anyway, you
> could move this all to the imperative.
Ah, yeah, I keep forgetting about this. I'll change it to imperative
if I send another version.
> > Makefile | 1 +
> > arch/arm64/Makefile | 3 +++
> > init/Kconfig | 2 +-
> > 3 files changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/Makefile b/Makefile
> > index 44c02a6f60a1..eb01a26d8354 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/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/init/Kconfig b/init/Kconfig
> > index fe76c5d0a72e..d857f6f90885 100644
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -1909,7 +1909,7 @@ config RUST
> > depends on !MODVERSIONS
> > depends on !GCC_PLUGINS
> > depends on !RANDSTRUCT
> > - depends on !SHADOW_CALL_STACK
> > + depends on !SHADOW_CALL_STACK || RUSTC_VERSION >= 108000 && UNWIND_PATCH_PAC_INTO_SCS
>
> Sorry, I didn't spot this in v4, but since UNWIND_PATCH_PAC_INTO_SCS is
> specific to arm64 and the only other architecture selecting
> ARCH_SUPPORTS_SHADOW_CALL_STACK is riscv, I can't help but feel it would
> be cleaner to move this logic into the arch code selecting HAVE_RUST.
>
> That is, it's up to the architecture to make sure that it has whatever
> it needs for SCS to work with Rust if it claims to support Rust.
>
> What do you think?
The `select RUST if ...` is going to get really complicated if we
apply that rule in general. Having options here allows us to split
them across several `depends on` clauses. I'm not sure it will even
work, I had issues with cyclic Kconfig errors previously. I also don't
think it's unreasonable for the architecture to say it supports both
options when it really does support both; they are just mutually
exclusive. I also think there is value in having all of the options
that Rust doesn't work with in one place.
So I'd like to keep it as-is.
Alice
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v5] rust: support for shadow call stack sanitizer
2024-08-20 15:13 ` Alice Ryhl
@ 2024-08-23 12:24 ` Will Deacon
2024-08-23 12:38 ` Alice Ryhl
0 siblings, 1 reply; 11+ messages in thread
From: Will Deacon @ 2024-08-23 12:24 UTC (permalink / raw)
To: Alice Ryhl
Cc: Catalin Marinas, Jamie Cunliffe, Sami Tolvanen, Nathan Chancellor,
Conor Dooley, Masahiro Yamada, Nicolas Schier, Ard Biesheuvel,
Marc Zyngier, Mark Rutland, Mark Brown, Nick Desaulniers,
Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Valentin Obst, linux-kbuild, linux-kernel, linux-arm-kernel,
rust-for-linux, Kees Cook
On Tue, Aug 20, 2024 at 05:13:58PM +0200, Alice Ryhl wrote:
> On Tue, Aug 20, 2024 at 4:35 PM Will Deacon <will@kernel.org> wrote:
> > On Tue, Aug 06, 2024 at 10:01:44AM +0000, Alice Ryhl wrote:
> > > diff --git a/init/Kconfig b/init/Kconfig
> > > index fe76c5d0a72e..d857f6f90885 100644
> > > --- a/init/Kconfig
> > > +++ b/init/Kconfig
> > > @@ -1909,7 +1909,7 @@ config RUST
> > > depends on !MODVERSIONS
> > > depends on !GCC_PLUGINS
> > > depends on !RANDSTRUCT
> > > - depends on !SHADOW_CALL_STACK
> > > + depends on !SHADOW_CALL_STACK || RUSTC_VERSION >= 108000 && UNWIND_PATCH_PAC_INTO_SCS
> >
> > Sorry, I didn't spot this in v4, but since UNWIND_PATCH_PAC_INTO_SCS is
> > specific to arm64 and the only other architecture selecting
> > ARCH_SUPPORTS_SHADOW_CALL_STACK is riscv, I can't help but feel it would
> > be cleaner to move this logic into the arch code selecting HAVE_RUST.
> >
> > That is, it's up to the architecture to make sure that it has whatever
> > it needs for SCS to work with Rust if it claims to support Rust.
> >
> > What do you think?
>
> The `select RUST if ...` is going to get really complicated if we
> apply that rule in general. Having options here allows us to split
> them across several `depends on` clauses. I'm not sure it will even
> work, I had issues with cyclic Kconfig errors previously. I also don't
> think it's unreasonable for the architecture to say it supports both
> options when it really does support both; they are just mutually
> exclusive. I also think there is value in having all of the options
> that Rust doesn't work with in one place.
I'm not sure I follow why this will get really complicated. Isn't it as
straightforward as the diff below, or did I miss something?
Will
--->8
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index a2f8ff354ca6..2f5702cb9dac 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,11 @@ config ARM64
help
ARM 64-bit (AArch64) Linux support.
+config RUSTC_SUPPORTS_ARM64
+ bool
+ depends on CPU_LITTLE_ENDIAN
+ depends on !SHADOW_CALL_STACK || RUSTC_VERSION >= 108000 && UNWIND_PATCH_PAC_INTO_SC
+
config CLANG_SUPPORTS_DYNAMIC_FTRACE_WITH_ARGS
def_bool CC_IS_CLANG
# https://github.com/ClangBuiltLinux/linux/issues/1507
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 0f3cd7c3a436..93858dbfefc0 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 64BIT && !SHADOW_CALL_STACK
select HAVE_SAMPLE_FTRACE_DIRECT
select HAVE_SAMPLE_FTRACE_DIRECT_MULTI
select HAVE_STACKPROTECTOR
diff --git a/init/Kconfig b/init/Kconfig
index 5783a0b87517..3ada33b1d681 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1902,7 +1902,6 @@ config RUST
depends on !MODVERSIONS
depends on !GCC_PLUGINS
depends on !RANDSTRUCT
- depends on !SHADOW_CALL_STACK
depends on !DEBUG_INFO_BTF || PAHOLE_HAS_LANG_EXCLUDE
help
Enables Rust support in the kernel.
^ permalink raw reply related [flat|nested] 11+ messages in thread* Re: [PATCH v5] rust: support for shadow call stack sanitizer
2024-08-23 12:24 ` Will Deacon
@ 2024-08-23 12:38 ` Alice Ryhl
2024-08-23 12:57 ` Will Deacon
0 siblings, 1 reply; 11+ messages in thread
From: Alice Ryhl @ 2024-08-23 12:38 UTC (permalink / raw)
To: Will Deacon
Cc: Catalin Marinas, Jamie Cunliffe, Sami Tolvanen, Nathan Chancellor,
Conor Dooley, Masahiro Yamada, Nicolas Schier, Ard Biesheuvel,
Marc Zyngier, Mark Rutland, Mark Brown, Nick Desaulniers,
Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Valentin Obst, linux-kbuild, linux-kernel, linux-arm-kernel,
rust-for-linux, Kees Cook
On Fri, Aug 23, 2024 at 2:24 PM Will Deacon <will@kernel.org> wrote:
>
> On Tue, Aug 20, 2024 at 05:13:58PM +0200, Alice Ryhl wrote:
> > On Tue, Aug 20, 2024 at 4:35 PM Will Deacon <will@kernel.org> wrote:
> > > On Tue, Aug 06, 2024 at 10:01:44AM +0000, Alice Ryhl wrote:
> > > > diff --git a/init/Kconfig b/init/Kconfig
> > > > index fe76c5d0a72e..d857f6f90885 100644
> > > > --- a/init/Kconfig
> > > > +++ b/init/Kconfig
> > > > @@ -1909,7 +1909,7 @@ config RUST
> > > > depends on !MODVERSIONS
> > > > depends on !GCC_PLUGINS
> > > > depends on !RANDSTRUCT
> > > > - depends on !SHADOW_CALL_STACK
> > > > + depends on !SHADOW_CALL_STACK || RUSTC_VERSION >= 108000 && UNWIND_PATCH_PAC_INTO_SCS
> > >
> > > Sorry, I didn't spot this in v4, but since UNWIND_PATCH_PAC_INTO_SCS is
> > > specific to arm64 and the only other architecture selecting
> > > ARCH_SUPPORTS_SHADOW_CALL_STACK is riscv, I can't help but feel it would
> > > be cleaner to move this logic into the arch code selecting HAVE_RUST.
> > >
> > > That is, it's up to the architecture to make sure that it has whatever
> > > it needs for SCS to work with Rust if it claims to support Rust.
> > >
> > > What do you think?
> >
> > The `select RUST if ...` is going to get really complicated if we
> > apply that rule in general. Having options here allows us to split
> > them across several `depends on` clauses. I'm not sure it will even
> > work, I had issues with cyclic Kconfig errors previously. I also don't
> > think it's unreasonable for the architecture to say it supports both
> > options when it really does support both; they are just mutually
> > exclusive. I also think there is value in having all of the options
> > that Rust doesn't work with in one place.
>
> I'm not sure I follow why this will get really complicated. Isn't it as
> straightforward as the diff below, or did I miss something?
Hmm. I tried this but I wasn't able to enable Rust with this setup.
Even though the deps of RUSTC_SUPPORTS_ARM64 are ok, it doesn't seem
to be enabled and I can't find it in menuconfig. I think we need to
have a `select RUSTC_SUPPORTS_ARM64` somewhere.
Alice
> --->8
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index a2f8ff354ca6..2f5702cb9dac 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,11 @@ config ARM64
> help
> ARM 64-bit (AArch64) Linux support.
>
> +config RUSTC_SUPPORTS_ARM64
> + bool
> + depends on CPU_LITTLE_ENDIAN
> + depends on !SHADOW_CALL_STACK || RUSTC_VERSION >= 108000 && UNWIND_PATCH_PAC_INTO_SC
> +
> config CLANG_SUPPORTS_DYNAMIC_FTRACE_WITH_ARGS
> def_bool CC_IS_CLANG
> # https://github.com/ClangBuiltLinux/linux/issues/1507
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 0f3cd7c3a436..93858dbfefc0 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 64BIT && !SHADOW_CALL_STACK
> select HAVE_SAMPLE_FTRACE_DIRECT
> select HAVE_SAMPLE_FTRACE_DIRECT_MULTI
> select HAVE_STACKPROTECTOR
> diff --git a/init/Kconfig b/init/Kconfig
> index 5783a0b87517..3ada33b1d681 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1902,7 +1902,6 @@ config RUST
> depends on !MODVERSIONS
> depends on !GCC_PLUGINS
> depends on !RANDSTRUCT
> - depends on !SHADOW_CALL_STACK
> depends on !DEBUG_INFO_BTF || PAHOLE_HAS_LANG_EXCLUDE
> help
> Enables Rust support in the kernel.
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v5] rust: support for shadow call stack sanitizer
2024-08-23 12:38 ` Alice Ryhl
@ 2024-08-23 12:57 ` Will Deacon
2024-08-23 13:09 ` Alice Ryhl
0 siblings, 1 reply; 11+ messages in thread
From: Will Deacon @ 2024-08-23 12:57 UTC (permalink / raw)
To: Alice Ryhl
Cc: Catalin Marinas, Jamie Cunliffe, Sami Tolvanen, Nathan Chancellor,
Conor Dooley, Masahiro Yamada, Nicolas Schier, Ard Biesheuvel,
Marc Zyngier, Mark Rutland, Mark Brown, Nick Desaulniers,
Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Valentin Obst, linux-kbuild, linux-kernel, linux-arm-kernel,
rust-for-linux, Kees Cook
On Fri, Aug 23, 2024 at 02:38:20PM +0200, Alice Ryhl wrote:
> On Fri, Aug 23, 2024 at 2:24 PM Will Deacon <will@kernel.org> wrote:
> >
> > On Tue, Aug 20, 2024 at 05:13:58PM +0200, Alice Ryhl wrote:
> > > On Tue, Aug 20, 2024 at 4:35 PM Will Deacon <will@kernel.org> wrote:
> > > > On Tue, Aug 06, 2024 at 10:01:44AM +0000, Alice Ryhl wrote:
> > > > > diff --git a/init/Kconfig b/init/Kconfig
> > > > > index fe76c5d0a72e..d857f6f90885 100644
> > > > > --- a/init/Kconfig
> > > > > +++ b/init/Kconfig
> > > > > @@ -1909,7 +1909,7 @@ config RUST
> > > > > depends on !MODVERSIONS
> > > > > depends on !GCC_PLUGINS
> > > > > depends on !RANDSTRUCT
> > > > > - depends on !SHADOW_CALL_STACK
> > > > > + depends on !SHADOW_CALL_STACK || RUSTC_VERSION >= 108000 && UNWIND_PATCH_PAC_INTO_SCS
> > > >
> > > > Sorry, I didn't spot this in v4, but since UNWIND_PATCH_PAC_INTO_SCS is
> > > > specific to arm64 and the only other architecture selecting
> > > > ARCH_SUPPORTS_SHADOW_CALL_STACK is riscv, I can't help but feel it would
> > > > be cleaner to move this logic into the arch code selecting HAVE_RUST.
> > > >
> > > > That is, it's up to the architecture to make sure that it has whatever
> > > > it needs for SCS to work with Rust if it claims to support Rust.
> > > >
> > > > What do you think?
> > >
> > > The `select RUST if ...` is going to get really complicated if we
> > > apply that rule in general. Having options here allows us to split
> > > them across several `depends on` clauses. I'm not sure it will even
> > > work, I had issues with cyclic Kconfig errors previously. I also don't
> > > think it's unreasonable for the architecture to say it supports both
> > > options when it really does support both; they are just mutually
> > > exclusive. I also think there is value in having all of the options
> > > that Rust doesn't work with in one place.
> >
> > I'm not sure I follow why this will get really complicated. Isn't it as
> > straightforward as the diff below, or did I miss something?
>
> Hmm. I tried this but I wasn't able to enable Rust with this setup.
> Even though the deps of RUSTC_SUPPORTS_ARM64 are ok, it doesn't seem
> to be enabled and I can't find it in menuconfig. I think we need to
> have a `select RUSTC_SUPPORTS_ARM64` somewhere.
Sorry, yes, my diff was a little half-arsed:
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index a2f8ff354ca6..2f5702cb9dac 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,11 @@ config ARM64
> > help
> > ARM 64-bit (AArch64) Linux support.
> >
> > +config RUSTC_SUPPORTS_ARM64
> > + bool
This line ^^^ should be 'def_bool y'.
Will
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v5] rust: support for shadow call stack sanitizer
2024-08-23 12:57 ` Will Deacon
@ 2024-08-23 13:09 ` Alice Ryhl
2024-08-23 13:21 ` Will Deacon
0 siblings, 1 reply; 11+ messages in thread
From: Alice Ryhl @ 2024-08-23 13:09 UTC (permalink / raw)
To: Will Deacon
Cc: Catalin Marinas, Jamie Cunliffe, Sami Tolvanen, Nathan Chancellor,
Conor Dooley, Masahiro Yamada, Nicolas Schier, Ard Biesheuvel,
Marc Zyngier, Mark Rutland, Mark Brown, Nick Desaulniers,
Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Valentin Obst, linux-kbuild, linux-kernel, linux-arm-kernel,
rust-for-linux, Kees Cook
On Fri, Aug 23, 2024 at 2:57 PM Will Deacon <will@kernel.org> wrote:
>
> On Fri, Aug 23, 2024 at 02:38:20PM +0200, Alice Ryhl wrote:
> > On Fri, Aug 23, 2024 at 2:24 PM Will Deacon <will@kernel.org> wrote:
> > >
> > > On Tue, Aug 20, 2024 at 05:13:58PM +0200, Alice Ryhl wrote:
> > > > On Tue, Aug 20, 2024 at 4:35 PM Will Deacon <will@kernel.org> wrote:
> > > > > On Tue, Aug 06, 2024 at 10:01:44AM +0000, Alice Ryhl wrote:
> > > > > > diff --git a/init/Kconfig b/init/Kconfig
> > > > > > index fe76c5d0a72e..d857f6f90885 100644
> > > > > > --- a/init/Kconfig
> > > > > > +++ b/init/Kconfig
> > > > > > @@ -1909,7 +1909,7 @@ config RUST
> > > > > > depends on !MODVERSIONS
> > > > > > depends on !GCC_PLUGINS
> > > > > > depends on !RANDSTRUCT
> > > > > > - depends on !SHADOW_CALL_STACK
> > > > > > + depends on !SHADOW_CALL_STACK || RUSTC_VERSION >= 108000 && UNWIND_PATCH_PAC_INTO_SCS
> > > > >
> > > > > Sorry, I didn't spot this in v4, but since UNWIND_PATCH_PAC_INTO_SCS is
> > > > > specific to arm64 and the only other architecture selecting
> > > > > ARCH_SUPPORTS_SHADOW_CALL_STACK is riscv, I can't help but feel it would
> > > > > be cleaner to move this logic into the arch code selecting HAVE_RUST.
> > > > >
> > > > > That is, it's up to the architecture to make sure that it has whatever
> > > > > it needs for SCS to work with Rust if it claims to support Rust.
> > > > >
> > > > > What do you think?
> > > >
> > > > The `select RUST if ...` is going to get really complicated if we
> > > > apply that rule in general. Having options here allows us to split
> > > > them across several `depends on` clauses. I'm not sure it will even
> > > > work, I had issues with cyclic Kconfig errors previously. I also don't
> > > > think it's unreasonable for the architecture to say it supports both
> > > > options when it really does support both; they are just mutually
> > > > exclusive. I also think there is value in having all of the options
> > > > that Rust doesn't work with in one place.
> > >
> > > I'm not sure I follow why this will get really complicated. Isn't it as
> > > straightforward as the diff below, or did I miss something?
> >
> > Hmm. I tried this but I wasn't able to enable Rust with this setup.
> > Even though the deps of RUSTC_SUPPORTS_ARM64 are ok, it doesn't seem
> > to be enabled and I can't find it in menuconfig. I think we need to
> > have a `select RUSTC_SUPPORTS_ARM64` somewhere.
>
> Sorry, yes, my diff was a little half-arsed:
>
> > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > > index a2f8ff354ca6..2f5702cb9dac 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,11 @@ config ARM64
> > > help
> > > ARM 64-bit (AArch64) Linux support.
> > >
> > > +config RUSTC_SUPPORTS_ARM64
> > > + bool
>
> This line ^^^ should be 'def_bool y'.
Ah, I see, I guess I learned something today. It also seems to work if
I add `default y`.
I can change it if you think this is better. I still think there's
some value in having everything in one place, but it's not a big deal.
Either way, it should be temporary for a few kernel releases as we'll
eventually only support compiler versions where this works.
Alice
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v5] rust: support for shadow call stack sanitizer
2024-08-23 13:09 ` Alice Ryhl
@ 2024-08-23 13:21 ` Will Deacon
2024-08-27 11:36 ` Alice Ryhl
0 siblings, 1 reply; 11+ messages in thread
From: Will Deacon @ 2024-08-23 13:21 UTC (permalink / raw)
To: Alice Ryhl
Cc: Catalin Marinas, Jamie Cunliffe, Sami Tolvanen, Nathan Chancellor,
Conor Dooley, Masahiro Yamada, Nicolas Schier, Ard Biesheuvel,
Marc Zyngier, Mark Rutland, Mark Brown, Nick Desaulniers,
Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Valentin Obst, linux-kbuild, linux-kernel, linux-arm-kernel,
rust-for-linux, Kees Cook
On Fri, Aug 23, 2024 at 03:09:40PM +0200, Alice Ryhl wrote:
> On Fri, Aug 23, 2024 at 2:57 PM Will Deacon <will@kernel.org> wrote:
> >
> > On Fri, Aug 23, 2024 at 02:38:20PM +0200, Alice Ryhl wrote:
> > > On Fri, Aug 23, 2024 at 2:24 PM Will Deacon <will@kernel.org> wrote:
> > > >
> > > > On Tue, Aug 20, 2024 at 05:13:58PM +0200, Alice Ryhl wrote:
> > > > > On Tue, Aug 20, 2024 at 4:35 PM Will Deacon <will@kernel.org> wrote:
> > > > > > On Tue, Aug 06, 2024 at 10:01:44AM +0000, Alice Ryhl wrote:
> > > > > > > diff --git a/init/Kconfig b/init/Kconfig
> > > > > > > index fe76c5d0a72e..d857f6f90885 100644
> > > > > > > --- a/init/Kconfig
> > > > > > > +++ b/init/Kconfig
> > > > > > > @@ -1909,7 +1909,7 @@ config RUST
> > > > > > > depends on !MODVERSIONS
> > > > > > > depends on !GCC_PLUGINS
> > > > > > > depends on !RANDSTRUCT
> > > > > > > - depends on !SHADOW_CALL_STACK
> > > > > > > + depends on !SHADOW_CALL_STACK || RUSTC_VERSION >= 108000 && UNWIND_PATCH_PAC_INTO_SCS
> > > > > >
> > > > > > Sorry, I didn't spot this in v4, but since UNWIND_PATCH_PAC_INTO_SCS is
> > > > > > specific to arm64 and the only other architecture selecting
> > > > > > ARCH_SUPPORTS_SHADOW_CALL_STACK is riscv, I can't help but feel it would
> > > > > > be cleaner to move this logic into the arch code selecting HAVE_RUST.
> > > > > >
> > > > > > That is, it's up to the architecture to make sure that it has whatever
> > > > > > it needs for SCS to work with Rust if it claims to support Rust.
> > > > > >
> > > > > > What do you think?
> > > > >
> > > > > The `select RUST if ...` is going to get really complicated if we
> > > > > apply that rule in general. Having options here allows us to split
> > > > > them across several `depends on` clauses. I'm not sure it will even
> > > > > work, I had issues with cyclic Kconfig errors previously. I also don't
> > > > > think it's unreasonable for the architecture to say it supports both
> > > > > options when it really does support both; they are just mutually
> > > > > exclusive. I also think there is value in having all of the options
> > > > > that Rust doesn't work with in one place.
> > > >
> > > > I'm not sure I follow why this will get really complicated. Isn't it as
> > > > straightforward as the diff below, or did I miss something?
> > >
> > > Hmm. I tried this but I wasn't able to enable Rust with this setup.
> > > Even though the deps of RUSTC_SUPPORTS_ARM64 are ok, it doesn't seem
> > > to be enabled and I can't find it in menuconfig. I think we need to
> > > have a `select RUSTC_SUPPORTS_ARM64` somewhere.
> >
> > Sorry, yes, my diff was a little half-arsed:
> >
> > > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > > > index a2f8ff354ca6..2f5702cb9dac 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,11 @@ config ARM64
> > > > help
> > > > ARM 64-bit (AArch64) Linux support.
> > > >
> > > > +config RUSTC_SUPPORTS_ARM64
> > > > + bool
> >
> > This line ^^^ should be 'def_bool y'.
>
> Ah, I see, I guess I learned something today. It also seems to work if
> I add `default y`.
>
> I can change it if you think this is better. I still think there's
> some value in having everything in one place, but it's not a big deal.
> Either way, it should be temporary for a few kernel releases as we'll
> eventually only support compiler versions where this works.
I do like moving the reference to UNWIND_PATCH_PAC_INTO_SCS into the
arch code, so if you could respin along these lines then that would be
great.
Thanks,
Will
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v5] rust: support for shadow call stack sanitizer
2024-08-23 13:21 ` Will Deacon
@ 2024-08-27 11:36 ` Alice Ryhl
0 siblings, 0 replies; 11+ messages in thread
From: Alice Ryhl @ 2024-08-27 11:36 UTC (permalink / raw)
To: Will Deacon
Cc: Catalin Marinas, Jamie Cunliffe, Sami Tolvanen, Nathan Chancellor,
Conor Dooley, Masahiro Yamada, Nicolas Schier, Ard Biesheuvel,
Marc Zyngier, Mark Rutland, Mark Brown, Nick Desaulniers,
Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Valentin Obst, linux-kbuild, linux-kernel, linux-arm-kernel,
rust-for-linux, Kees Cook
On Fri, Aug 23, 2024 at 3:21 PM Will Deacon <will@kernel.org> wrote:
>
> On Fri, Aug 23, 2024 at 03:09:40PM +0200, Alice Ryhl wrote:
> > On Fri, Aug 23, 2024 at 2:57 PM Will Deacon <will@kernel.org> wrote:
> > >
> > > On Fri, Aug 23, 2024 at 02:38:20PM +0200, Alice Ryhl wrote:
> > > > On Fri, Aug 23, 2024 at 2:24 PM Will Deacon <will@kernel.org> wrote:
> > > > >
> > > > > On Tue, Aug 20, 2024 at 05:13:58PM +0200, Alice Ryhl wrote:
> > > > > > On Tue, Aug 20, 2024 at 4:35 PM Will Deacon <will@kernel.org> wrote:
> > > > > > > On Tue, Aug 06, 2024 at 10:01:44AM +0000, Alice Ryhl wrote:
> > > > > > > > diff --git a/init/Kconfig b/init/Kconfig
> > > > > > > > index fe76c5d0a72e..d857f6f90885 100644
> > > > > > > > --- a/init/Kconfig
> > > > > > > > +++ b/init/Kconfig
> > > > > > > > @@ -1909,7 +1909,7 @@ config RUST
> > > > > > > > depends on !MODVERSIONS
> > > > > > > > depends on !GCC_PLUGINS
> > > > > > > > depends on !RANDSTRUCT
> > > > > > > > - depends on !SHADOW_CALL_STACK
> > > > > > > > + depends on !SHADOW_CALL_STACK || RUSTC_VERSION >= 108000 && UNWIND_PATCH_PAC_INTO_SCS
> > > > > > >
> > > > > > > Sorry, I didn't spot this in v4, but since UNWIND_PATCH_PAC_INTO_SCS is
> > > > > > > specific to arm64 and the only other architecture selecting
> > > > > > > ARCH_SUPPORTS_SHADOW_CALL_STACK is riscv, I can't help but feel it would
> > > > > > > be cleaner to move this logic into the arch code selecting HAVE_RUST.
> > > > > > >
> > > > > > > That is, it's up to the architecture to make sure that it has whatever
> > > > > > > it needs for SCS to work with Rust if it claims to support Rust.
> > > > > > >
> > > > > > > What do you think?
> > > > > >
> > > > > > The `select RUST if ...` is going to get really complicated if we
> > > > > > apply that rule in general. Having options here allows us to split
> > > > > > them across several `depends on` clauses. I'm not sure it will even
> > > > > > work, I had issues with cyclic Kconfig errors previously. I also don't
> > > > > > think it's unreasonable for the architecture to say it supports both
> > > > > > options when it really does support both; they are just mutually
> > > > > > exclusive. I also think there is value in having all of the options
> > > > > > that Rust doesn't work with in one place.
> > > > >
> > > > > I'm not sure I follow why this will get really complicated. Isn't it as
> > > > > straightforward as the diff below, or did I miss something?
> > > >
> > > > Hmm. I tried this but I wasn't able to enable Rust with this setup.
> > > > Even though the deps of RUSTC_SUPPORTS_ARM64 are ok, it doesn't seem
> > > > to be enabled and I can't find it in menuconfig. I think we need to
> > > > have a `select RUSTC_SUPPORTS_ARM64` somewhere.
> > >
> > > Sorry, yes, my diff was a little half-arsed:
> > >
> > > > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > > > > index a2f8ff354ca6..2f5702cb9dac 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,11 @@ config ARM64
> > > > > help
> > > > > ARM 64-bit (AArch64) Linux support.
> > > > >
> > > > > +config RUSTC_SUPPORTS_ARM64
> > > > > + bool
> > >
> > > This line ^^^ should be 'def_bool y'.
> >
> > Ah, I see, I guess I learned something today. It also seems to work if
> > I add `default y`.
> >
> > I can change it if you think this is better. I still think there's
> > some value in having everything in one place, but it's not a big deal.
> > Either way, it should be temporary for a few kernel releases as we'll
> > eventually only support compiler versions where this works.
>
> I do like moving the reference to UNWIND_PATCH_PAC_INTO_SCS into the
> arch code, so if you could respin along these lines then that would be
> great.
Done, see:
https://lore.kernel.org/all/20240826-shadow-call-stack-v6-1-495a7e3eb0ef@google.com/
I took the opportunity to incorporate new developments in rustc
changes into the Kconfig rules.
Alice
^ permalink raw reply [flat|nested] 11+ messages in thread