| Message ID | 20240806-shadow-call-stack-v5-1-26dccb829154@google.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [v5] rust: support for shadow call stack sanitizer | expand |
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>
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
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
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
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.
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. >
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
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
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
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
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 depends on !DEBUG_INFO_BTF || PAHOLE_HAS_LANG_EXCLUDE help Enables Rust support in the kernel.
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> --- This patch depends on the next version of [1], which Miguel will send soon. Link: https://lore.kernel.org/rust-for-linux/20240709160615.998336-12-ojeda@kernel.org/ [1] --- 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/Makefile | 3 +++ init/Kconfig | 2 +- 3 files changed, 5 insertions(+), 1 deletion(-) --- base-commit: 5953fd808fca8116a91678ee5fac00fc198ad93d change-id: 20240304-shadow-call-stack-9c197a4361d9 Best regards,