* [PATCH v4] ARM: Implement SLS mitigation
@ 2021-02-19 23:08 ` Jian Cai
0 siblings, 0 replies; 58+ messages in thread
From: Jian Cai @ 2021-02-19 23:08 UTC (permalink / raw)
Cc: Mark Rutland, Catalin Marinas, Linus Walleij, James Morris,
manojgupta, Will Deacon, Ingo Molnar, Marc Zyngier,
Masahiro Yamada, Russell King, Ard Biesheuvel, clang-built-linux,
llozano, David Brazdil, Serge E. Hallyn, Kees Cook,
Arnd Bergmann, Jian Cai, Nathan Chancellor, linux-arm-kernel,
ndesaulniers, linux-kernel, linux-security-module, David Laight,
James Morse, Andrew Morton, Andreas Färber, Mike Rapoport
This patch adds CONFIG_HARDEN_SLS_ALL that can be used to turn on
-mharden-sls=all, which mitigates the straight-line speculation
vulnerability, speculative execution of the instruction following some
unconditional jumps. Notice -mharden-sls= has other options as below,
and this config turns on the strongest option.
all: enable all mitigations against Straight Line Speculation that are implemented.
none: disable all mitigations against Straight Line Speculation.
retbr: enable the mitigation against Straight Line Speculation for RET and BR instructions.
blr: enable the mitigation against Straight Line Speculation for BLR instructions.
Links:
https://reviews.llvm.org/D93221
https://reviews.llvm.org/D81404
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/frequently-asked-questions#SLS2
Suggested-by: Manoj Gupta <manojgupta@google.com>
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Suggested-by: Nathan Chancellor <nathan@kernel.org>
Suggested-by: David Laight <David.Laight@aculab.com>
Suggested-by: Will Deacon <will@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Jian Cai <jiancai@google.com>
---
Changes v3 -> v4:
Address Nathan's comment and replace def_bool with depends on in
HARDEN_SLS_ALL.
arch/arm/Makefile | 4 ++++
arch/arm/include/asm/vmlinux.lds.h | 4 ++++
arch/arm/kernel/vmlinux.lds.S | 1 +
arch/arm64/Makefile | 4 ++++
arch/arm64/kernel/vmlinux.lds.S | 5 +++++
security/Kconfig.hardening | 10 ++++++++++
6 files changed, 28 insertions(+)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 4aaec9599e8a..11d89ef32da9 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -48,6 +48,10 @@ CHECKFLAGS += -D__ARMEL__
KBUILD_LDFLAGS += -EL
endif
+ifeq ($(CONFIG_HARDEN_SLS_ALL), y)
+KBUILD_CFLAGS += -mharden-sls=all
+endif
+
#
# The Scalar Replacement of Aggregates (SRA) optimization pass in GCC 4.9 and
# later may result in code being generated that handles signed short and signed
diff --git a/arch/arm/include/asm/vmlinux.lds.h b/arch/arm/include/asm/vmlinux.lds.h
index 4a91428c324d..c7f9717511ca 100644
--- a/arch/arm/include/asm/vmlinux.lds.h
+++ b/arch/arm/include/asm/vmlinux.lds.h
@@ -145,3 +145,7 @@
__edtcm_data = .; \
} \
. = __dtcm_start + SIZEOF(.data_dtcm);
+
+#define SLS_TEXT \
+ ALIGN_FUNCTION(); \
+ *(.text.__llvm_slsblr_thunk_*)
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index f7f4620d59c3..e71f2bc97bae 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -63,6 +63,7 @@ SECTIONS
.text : { /* Real text segment */
_stext = .; /* Text and read-only data */
ARM_TEXT
+ SLS_TEXT
}
#ifdef CONFIG_DEBUG_ALIGN_RODATA
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 90309208bb28..ca7299b356a9 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -34,6 +34,10 @@ $(warning LSE atomics not supported by binutils)
endif
endif
+ifeq ($(CONFIG_HARDEN_SLS_ALL), y)
+KBUILD_CFLAGS += -mharden-sls=all
+endif
+
cc_has_k_constraint := $(call try-run,echo \
'int main(void) { \
asm volatile("and w0, w0, %w0" :: "K" (4294967295)); \
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 4c0b0c89ad59..f8912e42ffcd 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -93,6 +93,10 @@ jiffies = jiffies_64;
#define TRAMP_TEXT
#endif
+#define SLS_TEXT \
+ ALIGN_FUNCTION(); \
+ *(.text.__llvm_slsblr_thunk_*)
+
/*
* The size of the PE/COFF section that covers the kernel image, which
* runs from _stext to _edata, must be a round multiple of the PE/COFF
@@ -144,6 +148,7 @@ SECTIONS
HIBERNATE_TEXT
TRAMP_TEXT
*(.fixup)
+ SLS_TEXT
*(.gnu.warning)
. = ALIGN(16);
*(.got) /* Global offset table */
diff --git a/security/Kconfig.hardening b/security/Kconfig.hardening
index 269967c4fc1b..146b75a79d9e 100644
--- a/security/Kconfig.hardening
+++ b/security/Kconfig.hardening
@@ -121,6 +121,16 @@ choice
endchoice
+config HARDEN_SLS_ALL
+ bool "enable SLS vulnerability hardening"
+ default n
+ depends on $(cc-option,-mharden-sls=all)
+ help
+ Enables straight-line speculation vulnerability hardening on ARM and ARM64
+ architectures. It inserts speculation barrier sequences (SB or DSB+ISB
+ depending on the target architecture) after RET and BR, and replacing
+ BLR with BL+BR sequence.
+
config GCC_PLUGIN_STRUCTLEAK_VERBOSE
bool "Report forcefully initialized variables"
depends on GCC_PLUGIN_STRUCTLEAK
--
2.30.0.617.g56c4b15f3c-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 58+ messages in thread
* Re: [PATCH v4] ARM: Implement SLS mitigation
2021-02-19 23:08 ` Jian Cai
@ 2021-02-21 10:13 ` Russell King - ARM Linux admin
-1 siblings, 0 replies; 58+ messages in thread
From: Russell King - ARM Linux admin @ 2021-02-21 10:13 UTC (permalink / raw)
To: Jian Cai
Cc: Mark Rutland, Catalin Marinas, Linus Walleij, James Morris,
manojgupta, Will Deacon, Ingo Molnar, Marc Zyngier,
Masahiro Yamada, Ard Biesheuvel, clang-built-linux, llozano,
David Brazdil, Serge E. Hallyn, Kees Cook, Arnd Bergmann,
Nathan Chancellor, linux-arm-kernel, ndesaulniers, linux-kernel,
linux-security-module, David Laight, James Morse, Andrew Morton,
Andreas Färber, Mike Rapoport
On Fri, Feb 19, 2021 at 03:08:13PM -0800, Jian Cai wrote:
> diff --git a/security/Kconfig.hardening b/security/Kconfig.hardening
> index 269967c4fc1b..146b75a79d9e 100644
> --- a/security/Kconfig.hardening
> +++ b/security/Kconfig.hardening
> @@ -121,6 +121,16 @@ choice
>
> endchoice
>
> +config HARDEN_SLS_ALL
> + bool "enable SLS vulnerability hardening"
> + default n
Please get rid of this useless "default n"
> + depends on $(cc-option,-mharden-sls=all)
> + help
> + Enables straight-line speculation vulnerability hardening on ARM and ARM64
> + architectures. It inserts speculation barrier sequences (SB or DSB+ISB
> + depending on the target architecture) after RET and BR, and replacing
> + BLR with BL+BR sequence.
Given that this is in an architecture independent Kconfig file, and it
detects support in CC for this feature, why should this help text be
written to be specific to a couple of architectures? Will this feature
only ever be available on these two architectures? What if someone adds
support for another architecture?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v4] ARM: Implement SLS mitigation
@ 2021-02-21 10:13 ` Russell King - ARM Linux admin
0 siblings, 0 replies; 58+ messages in thread
From: Russell King - ARM Linux admin @ 2021-02-21 10:13 UTC (permalink / raw)
To: Jian Cai
Cc: Mark Rutland, Catalin Marinas, Linus Walleij, manojgupta,
Will Deacon, Ard Biesheuvel, Marc Zyngier, Masahiro Yamada,
James Morris, Ingo Molnar, clang-built-linux, llozano,
David Brazdil, Serge E. Hallyn, Kees Cook, Arnd Bergmann,
Nathan Chancellor, linux-arm-kernel, ndesaulniers, linux-kernel,
linux-security-module, David Laight, James Morse, Andrew Morton,
Andreas Färber, Mike Rapoport
On Fri, Feb 19, 2021 at 03:08:13PM -0800, Jian Cai wrote:
> diff --git a/security/Kconfig.hardening b/security/Kconfig.hardening
> index 269967c4fc1b..146b75a79d9e 100644
> --- a/security/Kconfig.hardening
> +++ b/security/Kconfig.hardening
> @@ -121,6 +121,16 @@ choice
>
> endchoice
>
> +config HARDEN_SLS_ALL
> + bool "enable SLS vulnerability hardening"
> + default n
Please get rid of this useless "default n"
> + depends on $(cc-option,-mharden-sls=all)
> + help
> + Enables straight-line speculation vulnerability hardening on ARM and ARM64
> + architectures. It inserts speculation barrier sequences (SB or DSB+ISB
> + depending on the target architecture) after RET and BR, and replacing
> + BLR with BL+BR sequence.
Given that this is in an architecture independent Kconfig file, and it
detects support in CC for this feature, why should this help text be
written to be specific to a couple of architectures? Will this feature
only ever be available on these two architectures? What if someone adds
support for another architecture?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v4] ARM: Implement SLS mitigation
2021-02-19 23:08 ` Jian Cai
@ 2021-02-22 11:58 ` Will Deacon
-1 siblings, 0 replies; 58+ messages in thread
From: Will Deacon @ 2021-02-22 11:58 UTC (permalink / raw)
To: Jian Cai
Cc: ndesaulniers, manojgupta, llozano, clang-built-linux,
Nathan Chancellor, David Laight, Russell King, Catalin Marinas,
James Morris, Serge E. Hallyn, Arnd Bergmann, Masahiro Yamada,
Kees Cook, Ard Biesheuvel, Andreas Färber, Ingo Molnar,
Linus Walleij, Marc Zyngier, Andrew Morton, Mike Rapoport,
Mark Rutland, David Brazdil, James Morse, linux-arm-kernel,
linux-kernel, linux-security-module
On Fri, Feb 19, 2021 at 03:08:13PM -0800, Jian Cai wrote:
> This patch adds CONFIG_HARDEN_SLS_ALL that can be used to turn on
> -mharden-sls=all, which mitigates the straight-line speculation
> vulnerability, speculative execution of the instruction following some
> unconditional jumps. Notice -mharden-sls= has other options as below,
> and this config turns on the strongest option.
>
> all: enable all mitigations against Straight Line Speculation that are implemented.
> none: disable all mitigations against Straight Line Speculation.
> retbr: enable the mitigation against Straight Line Speculation for RET and BR instructions.
> blr: enable the mitigation against Straight Line Speculation for BLR instructions.
>
> Links:
> https://reviews.llvm.org/D93221
> https://reviews.llvm.org/D81404
> https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation
> https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/frequently-asked-questions#SLS2
>
> Suggested-by: Manoj Gupta <manojgupta@google.com>
> Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
> Suggested-by: Nathan Chancellor <nathan@kernel.org>
> Suggested-by: David Laight <David.Laight@aculab.com>
> Suggested-by: Will Deacon <will@kernel.org>
> Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> Signed-off-by: Jian Cai <jiancai@google.com>
> ---
Please can you reply to my previous questions?
https://lore.kernel.org/linux-arm-kernel/20210217094859.GA3706@willie-the-truck/
(apologies if you did, but I don't see them in the archive or my inbox)
Will
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v4] ARM: Implement SLS mitigation
@ 2021-02-22 11:58 ` Will Deacon
0 siblings, 0 replies; 58+ messages in thread
From: Will Deacon @ 2021-02-22 11:58 UTC (permalink / raw)
To: Jian Cai
Cc: Mark Rutland, Catalin Marinas, Linus Walleij, James Morris,
manojgupta, Ingo Molnar, Marc Zyngier, Masahiro Yamada,
Russell King, Ard Biesheuvel, clang-built-linux, llozano,
David Brazdil, Serge E. Hallyn, Kees Cook, Arnd Bergmann,
Nathan Chancellor, linux-arm-kernel, ndesaulniers, linux-kernel,
linux-security-module, David Laight, James Morse, Andrew Morton,
Andreas Färber, Mike Rapoport
On Fri, Feb 19, 2021 at 03:08:13PM -0800, Jian Cai wrote:
> This patch adds CONFIG_HARDEN_SLS_ALL that can be used to turn on
> -mharden-sls=all, which mitigates the straight-line speculation
> vulnerability, speculative execution of the instruction following some
> unconditional jumps. Notice -mharden-sls= has other options as below,
> and this config turns on the strongest option.
>
> all: enable all mitigations against Straight Line Speculation that are implemented.
> none: disable all mitigations against Straight Line Speculation.
> retbr: enable the mitigation against Straight Line Speculation for RET and BR instructions.
> blr: enable the mitigation against Straight Line Speculation for BLR instructions.
>
> Links:
> https://reviews.llvm.org/D93221
> https://reviews.llvm.org/D81404
> https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation
> https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/frequently-asked-questions#SLS2
>
> Suggested-by: Manoj Gupta <manojgupta@google.com>
> Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
> Suggested-by: Nathan Chancellor <nathan@kernel.org>
> Suggested-by: David Laight <David.Laight@aculab.com>
> Suggested-by: Will Deacon <will@kernel.org>
> Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> Signed-off-by: Jian Cai <jiancai@google.com>
> ---
Please can you reply to my previous questions?
https://lore.kernel.org/linux-arm-kernel/20210217094859.GA3706@willie-the-truck/
(apologies if you did, but I don't see them in the archive or my inbox)
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v4] ARM: Implement SLS mitigation
2021-02-22 11:58 ` Will Deacon
@ 2021-02-22 21:50 ` Jian Cai
-1 siblings, 0 replies; 58+ messages in thread
From: Jian Cai @ 2021-02-22 21:50 UTC (permalink / raw)
To: Will Deacon
Cc: Nick Desaulniers, Manoj Gupta, Luis Lozano, clang-built-linux,
Nathan Chancellor, David Laight, Russell King, Catalin Marinas,
James Morris, Serge E. Hallyn, Arnd Bergmann, Masahiro Yamada,
Kees Cook, Ard Biesheuvel, Andreas Färber, Ingo Molnar,
Linus Walleij, Marc Zyngier, Andrew Morton, Mike Rapoport,
Mark Rutland, David Brazdil, James Morse, Linux ARM,
Linux Kernel Mailing List, linux-security-module
Please see my comments inlined below.
Thanks,
Jian
On Mon, Feb 22, 2021 at 3:58 AM Will Deacon <will@kernel.org> wrote:
>
> On Fri, Feb 19, 2021 at 03:08:13PM -0800, Jian Cai wrote:
> > This patch adds CONFIG_HARDEN_SLS_ALL that can be used to turn on
> > -mharden-sls=all, which mitigates the straight-line speculation
> > vulnerability, speculative execution of the instruction following some
> > unconditional jumps. Notice -mharden-sls= has other options as below,
> > and this config turns on the strongest option.
> >
> > all: enable all mitigations against Straight Line Speculation that are implemented.
> > none: disable all mitigations against Straight Line Speculation.
> > retbr: enable the mitigation against Straight Line Speculation for RET and BR instructions.
> > blr: enable the mitigation against Straight Line Speculation for BLR instructions.
> >
> > Links:
> > https://reviews.llvm.org/D93221
> > https://reviews.llvm.org/D81404
> > https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation
> > https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/frequently-asked-questions#SLS2
> >
> > Suggested-by: Manoj Gupta <manojgupta@google.com>
> > Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
> > Suggested-by: Nathan Chancellor <nathan@kernel.org>
> > Suggested-by: David Laight <David.Laight@aculab.com>
> > Suggested-by: Will Deacon <will@kernel.org>
> > Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> > Signed-off-by: Jian Cai <jiancai@google.com>
> > ---
>
> Please can you reply to my previous questions?
>
> https://lore.kernel.org/linux-arm-kernel/20210217094859.GA3706@willie-the-truck/
>
> (apologies if you did, but I don't see them in the archive or my inbox)
I should have clarified the suggested-by tag was in regard to the
Kconfig text change. Regarding your earlier questions, please see my
comments below.
> So I think that either we enable this unconditionally, or we don't enable it
> at all (and people can hack their CFLAGS themselves if they want to).
Not sure if this answers your question but this config should provide
a way for people to turn on the mitigation at their own risk.
> It would be helpful for one of the Arm folks to chime in, as I'm yet to see any
> evidence that this is actually exploitable. Is it any worse that Spectre-v1,
> where we _don't_ have a compiler mitigation?
> Finally, do we have to worry about our assembly code?
I am not sure if there are any plans to protect assembly code and I
will leave it to the Arm folks since they know a whole lot better. But
even without that part, we should still have better protection,
especially when overhead does not look too bad: I did some preliminary
experiments on ChromeOS, code size of vmlinux increased 3%, and there
were no noticeable changes to run-time performance of the benchmarks I
used.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v4] ARM: Implement SLS mitigation
@ 2021-02-22 21:50 ` Jian Cai
0 siblings, 0 replies; 58+ messages in thread
From: Jian Cai @ 2021-02-22 21:50 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Catalin Marinas, Linus Walleij, James Morris,
Manoj Gupta, Ingo Molnar, Marc Zyngier, Masahiro Yamada,
Russell King, Ard Biesheuvel, clang-built-linux, Luis Lozano,
David Brazdil, Serge E. Hallyn, Kees Cook, Arnd Bergmann,
Nathan Chancellor, Linux ARM, Nick Desaulniers,
Linux Kernel Mailing List, linux-security-module, David Laight,
James Morse, Andrew Morton, Andreas Färber, Mike Rapoport
Please see my comments inlined below.
Thanks,
Jian
On Mon, Feb 22, 2021 at 3:58 AM Will Deacon <will@kernel.org> wrote:
>
> On Fri, Feb 19, 2021 at 03:08:13PM -0800, Jian Cai wrote:
> > This patch adds CONFIG_HARDEN_SLS_ALL that can be used to turn on
> > -mharden-sls=all, which mitigates the straight-line speculation
> > vulnerability, speculative execution of the instruction following some
> > unconditional jumps. Notice -mharden-sls= has other options as below,
> > and this config turns on the strongest option.
> >
> > all: enable all mitigations against Straight Line Speculation that are implemented.
> > none: disable all mitigations against Straight Line Speculation.
> > retbr: enable the mitigation against Straight Line Speculation for RET and BR instructions.
> > blr: enable the mitigation against Straight Line Speculation for BLR instructions.
> >
> > Links:
> > https://reviews.llvm.org/D93221
> > https://reviews.llvm.org/D81404
> > https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation
> > https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/frequently-asked-questions#SLS2
> >
> > Suggested-by: Manoj Gupta <manojgupta@google.com>
> > Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
> > Suggested-by: Nathan Chancellor <nathan@kernel.org>
> > Suggested-by: David Laight <David.Laight@aculab.com>
> > Suggested-by: Will Deacon <will@kernel.org>
> > Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> > Signed-off-by: Jian Cai <jiancai@google.com>
> > ---
>
> Please can you reply to my previous questions?
>
> https://lore.kernel.org/linux-arm-kernel/20210217094859.GA3706@willie-the-truck/
>
> (apologies if you did, but I don't see them in the archive or my inbox)
I should have clarified the suggested-by tag was in regard to the
Kconfig text change. Regarding your earlier questions, please see my
comments below.
> So I think that either we enable this unconditionally, or we don't enable it
> at all (and people can hack their CFLAGS themselves if they want to).
Not sure if this answers your question but this config should provide
a way for people to turn on the mitigation at their own risk.
> It would be helpful for one of the Arm folks to chime in, as I'm yet to see any
> evidence that this is actually exploitable. Is it any worse that Spectre-v1,
> where we _don't_ have a compiler mitigation?
> Finally, do we have to worry about our assembly code?
I am not sure if there are any plans to protect assembly code and I
will leave it to the Arm folks since they know a whole lot better. But
even without that part, we should still have better protection,
especially when overhead does not look too bad: I did some preliminary
experiments on ChromeOS, code size of vmlinux increased 3%, and there
were no noticeable changes to run-time performance of the benchmarks I
used.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v4] ARM: Implement SLS mitigation
2021-02-22 21:50 ` Jian Cai
@ 2021-02-23 10:04 ` Will Deacon
-1 siblings, 0 replies; 58+ messages in thread
From: Will Deacon @ 2021-02-23 10:04 UTC (permalink / raw)
To: Jian Cai
Cc: Nick Desaulniers, Manoj Gupta, Luis Lozano, clang-built-linux,
Nathan Chancellor, David Laight, Russell King, Catalin Marinas,
James Morris, Serge E. Hallyn, Arnd Bergmann, Masahiro Yamada,
Kees Cook, Ard Biesheuvel, Andreas Färber, Ingo Molnar,
Linus Walleij, Marc Zyngier, Andrew Morton, Mike Rapoport,
Mark Rutland, David Brazdil, James Morse, Linux ARM,
Linux Kernel Mailing List, linux-security-module
On Mon, Feb 22, 2021 at 01:50:06PM -0800, Jian Cai wrote:
> Please see my comments inlined below.
>
> Thanks,
> Jian
>
> On Mon, Feb 22, 2021 at 3:58 AM Will Deacon <will@kernel.org> wrote:
> >
> > On Fri, Feb 19, 2021 at 03:08:13PM -0800, Jian Cai wrote:
> > > This patch adds CONFIG_HARDEN_SLS_ALL that can be used to turn on
> > > -mharden-sls=all, which mitigates the straight-line speculation
> > > vulnerability, speculative execution of the instruction following some
> > > unconditional jumps. Notice -mharden-sls= has other options as below,
> > > and this config turns on the strongest option.
> > >
> > > all: enable all mitigations against Straight Line Speculation that are implemented.
> > > none: disable all mitigations against Straight Line Speculation.
> > > retbr: enable the mitigation against Straight Line Speculation for RET and BR instructions.
> > > blr: enable the mitigation against Straight Line Speculation for BLR instructions.
> > >
> > > Links:
> > > https://reviews.llvm.org/D93221
> > > https://reviews.llvm.org/D81404
> > > https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation
> > > https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/frequently-asked-questions#SLS2
> > >
> > > Suggested-by: Manoj Gupta <manojgupta@google.com>
> > > Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
> > > Suggested-by: Nathan Chancellor <nathan@kernel.org>
> > > Suggested-by: David Laight <David.Laight@aculab.com>
> > > Suggested-by: Will Deacon <will@kernel.org>
> > > Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> > > Signed-off-by: Jian Cai <jiancai@google.com>
> > > ---
> >
> > Please can you reply to my previous questions?
> >
> > https://lore.kernel.org/linux-arm-kernel/20210217094859.GA3706@willie-the-truck/
> >
> > (apologies if you did, but I don't see them in the archive or my inbox)
>
> I should have clarified the suggested-by tag was in regard to the
> Kconfig text change. Regarding your earlier questions, please see my
> comments below.
>
> > So I think that either we enable this unconditionally, or we don't enable it
> > at all (and people can hack their CFLAGS themselves if they want to).
>
> Not sure if this answers your question but this config should provide
> a way for people to turn on the mitigation at their own risk.
I'm not sure I see the point; either it's needed or its not. I wonder if
there's a plan to fix this in future CPUs (another question for the Arm
folks).
> > It would be helpful for one of the Arm folks to chime in, as I'm yet to see any
> > evidence that this is actually exploitable. Is it any worse that Spectre-v1,
> > where we _don't_ have a compiler mitigation?
>
> > Finally, do we have to worry about our assembly code?
>
> I am not sure if there are any plans to protect assembly code and I
> will leave it to the Arm folks since they know a whole lot better. But
> even without that part, we should still have better protection,
> especially when overhead does not look too bad: I did some preliminary
> experiments on ChromeOS, code size of vmlinux increased 3%, and there
> were no noticeable changes to run-time performance of the benchmarks I
> used.
If the mitigation is required, I'm not sure I see a lot of point in only
doing a half-baked job of it. It feels a bit like a box-ticking exercise,
in which case any overhead is too much.
Will
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v4] ARM: Implement SLS mitigation
@ 2021-02-23 10:04 ` Will Deacon
0 siblings, 0 replies; 58+ messages in thread
From: Will Deacon @ 2021-02-23 10:04 UTC (permalink / raw)
To: Jian Cai
Cc: Mark Rutland, Catalin Marinas, Linus Walleij, James Morris,
Manoj Gupta, Ingo Molnar, Marc Zyngier, Masahiro Yamada,
Russell King, Ard Biesheuvel, clang-built-linux, Luis Lozano,
David Brazdil, Serge E. Hallyn, Kees Cook, Arnd Bergmann,
Nathan Chancellor, Linux ARM, Nick Desaulniers,
Linux Kernel Mailing List, linux-security-module, David Laight,
James Morse, Andrew Morton, Andreas Färber, Mike Rapoport
On Mon, Feb 22, 2021 at 01:50:06PM -0800, Jian Cai wrote:
> Please see my comments inlined below.
>
> Thanks,
> Jian
>
> On Mon, Feb 22, 2021 at 3:58 AM Will Deacon <will@kernel.org> wrote:
> >
> > On Fri, Feb 19, 2021 at 03:08:13PM -0800, Jian Cai wrote:
> > > This patch adds CONFIG_HARDEN_SLS_ALL that can be used to turn on
> > > -mharden-sls=all, which mitigates the straight-line speculation
> > > vulnerability, speculative execution of the instruction following some
> > > unconditional jumps. Notice -mharden-sls= has other options as below,
> > > and this config turns on the strongest option.
> > >
> > > all: enable all mitigations against Straight Line Speculation that are implemented.
> > > none: disable all mitigations against Straight Line Speculation.
> > > retbr: enable the mitigation against Straight Line Speculation for RET and BR instructions.
> > > blr: enable the mitigation against Straight Line Speculation for BLR instructions.
> > >
> > > Links:
> > > https://reviews.llvm.org/D93221
> > > https://reviews.llvm.org/D81404
> > > https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation
> > > https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/frequently-asked-questions#SLS2
> > >
> > > Suggested-by: Manoj Gupta <manojgupta@google.com>
> > > Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
> > > Suggested-by: Nathan Chancellor <nathan@kernel.org>
> > > Suggested-by: David Laight <David.Laight@aculab.com>
> > > Suggested-by: Will Deacon <will@kernel.org>
> > > Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> > > Signed-off-by: Jian Cai <jiancai@google.com>
> > > ---
> >
> > Please can you reply to my previous questions?
> >
> > https://lore.kernel.org/linux-arm-kernel/20210217094859.GA3706@willie-the-truck/
> >
> > (apologies if you did, but I don't see them in the archive or my inbox)
>
> I should have clarified the suggested-by tag was in regard to the
> Kconfig text change. Regarding your earlier questions, please see my
> comments below.
>
> > So I think that either we enable this unconditionally, or we don't enable it
> > at all (and people can hack their CFLAGS themselves if they want to).
>
> Not sure if this answers your question but this config should provide
> a way for people to turn on the mitigation at their own risk.
I'm not sure I see the point; either it's needed or its not. I wonder if
there's a plan to fix this in future CPUs (another question for the Arm
folks).
> > It would be helpful for one of the Arm folks to chime in, as I'm yet to see any
> > evidence that this is actually exploitable. Is it any worse that Spectre-v1,
> > where we _don't_ have a compiler mitigation?
>
> > Finally, do we have to worry about our assembly code?
>
> I am not sure if there are any plans to protect assembly code and I
> will leave it to the Arm folks since they know a whole lot better. But
> even without that part, we should still have better protection,
> especially when overhead does not look too bad: I did some preliminary
> experiments on ChromeOS, code size of vmlinux increased 3%, and there
> were no noticeable changes to run-time performance of the benchmarks I
> used.
If the mitigation is required, I'm not sure I see a lot of point in only
doing a half-baked job of it. It feels a bit like a box-ticking exercise,
in which case any overhead is too much.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v4] ARM: Implement SLS mitigation
2021-02-23 10:04 ` Will Deacon
@ 2021-03-03 15:18 ` Linus Walleij
-1 siblings, 0 replies; 58+ messages in thread
From: Linus Walleij @ 2021-03-03 15:18 UTC (permalink / raw)
To: Will Deacon
Cc: Jian Cai, Nick Desaulniers, Manoj Gupta, Luis Lozano,
clang-built-linux, Nathan Chancellor, David Laight, Russell King,
Catalin Marinas, James Morris, Serge E. Hallyn, Arnd Bergmann,
Masahiro Yamada, Kees Cook, Ard Biesheuvel, Andreas Färber,
Ingo Molnar, Marc Zyngier, Andrew Morton, Mike Rapoport,
Mark Rutland, David Brazdil, James Morse, Linux ARM,
Linux Kernel Mailing List, linux-security-module
On Tue, Feb 23, 2021 at 11:05 AM Will Deacon <will@kernel.org> wrote:
> On Mon, Feb 22, 2021 at 01:50:06PM -0800, Jian Cai wrote:
> > I am not sure if there are any plans to protect assembly code and I
> > will leave it to the Arm folks since they know a whole lot better. But
> > even without that part, we should still have better protection,
> > especially when overhead does not look too bad: I did some preliminary
> > experiments on ChromeOS, code size of vmlinux increased 3%, and there
> > were no noticeable changes to run-time performance of the benchmarks I
> > used.
>
> If the mitigation is required, I'm not sure I see a lot of point in only
> doing a half-baked job of it. It feels a bit like a box-ticking exercise,
> in which case any overhead is too much.
I wrote some suggestions on follow-ups in my reply, and I can
help out doing some of the patches, I think.
Since ARM32 RET is mov pc, <>
git grep 'mov.*pc,' | wc -l gives 93 sites in arch/arm.
I suppose these need to come out:
mov pc, lr
dsb(nsh);
isb();
As ARM32 doesn't have sb my idea is to make a macro
"sb" that resolves to dsb/isb when this is enabled and then
we could start patching all the assembly users with that as
well. I need the Kconfig symbol from this patch though.
I also suggest selecting this mitigation as part of
HARDEN_BRANCH_PREDICTOR, by the token that either
you want all of them or none of them.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v4] ARM: Implement SLS mitigation
@ 2021-03-03 15:18 ` Linus Walleij
0 siblings, 0 replies; 58+ messages in thread
From: Linus Walleij @ 2021-03-03 15:18 UTC (permalink / raw)
To: Will Deacon
Cc: Jian Cai, Nick Desaulniers, Manoj Gupta, Luis Lozano,
clang-built-linux, Nathan Chancellor, David Laight, Russell King,
Catalin Marinas, James Morris, Serge E. Hallyn, Arnd Bergmann,
Masahiro Yamada, Kees Cook, Ard Biesheuvel, Andreas Färber,
Ingo Molnar, Marc Zyngier, Andrew Morton, Mike Rapoport,
Mark Rutland, David Brazdil, James Morse, Linux ARM,
Linux Kernel Mailing List, linux-security-module
On Tue, Feb 23, 2021 at 11:05 AM Will Deacon <will@kernel.org> wrote:
> On Mon, Feb 22, 2021 at 01:50:06PM -0800, Jian Cai wrote:
> > I am not sure if there are any plans to protect assembly code and I
> > will leave it to the Arm folks since they know a whole lot better. But
> > even without that part, we should still have better protection,
> > especially when overhead does not look too bad: I did some preliminary
> > experiments on ChromeOS, code size of vmlinux increased 3%, and there
> > were no noticeable changes to run-time performance of the benchmarks I
> > used.
>
> If the mitigation is required, I'm not sure I see a lot of point in only
> doing a half-baked job of it. It feels a bit like a box-ticking exercise,
> in which case any overhead is too much.
I wrote some suggestions on follow-ups in my reply, and I can
help out doing some of the patches, I think.
Since ARM32 RET is mov pc, <>
git grep 'mov.*pc,' | wc -l gives 93 sites in arch/arm.
I suppose these need to come out:
mov pc, lr
dsb(nsh);
isb();
As ARM32 doesn't have sb my idea is to make a macro
"sb" that resolves to dsb/isb when this is enabled and then
we could start patching all the assembly users with that as
well. I need the Kconfig symbol from this patch though.
I also suggest selecting this mitigation as part of
HARDEN_BRANCH_PREDICTOR, by the token that either
you want all of them or none of them.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 58+ messages in thread
* RE: [PATCH v4] ARM: Implement SLS mitigation
2021-03-03 15:18 ` Linus Walleij
@ 2021-03-03 15:29 ` David Laight
-1 siblings, 0 replies; 58+ messages in thread
From: David Laight @ 2021-03-03 15:29 UTC (permalink / raw)
To: 'Linus Walleij', Will Deacon
Cc: Jian Cai, Nick Desaulniers, Manoj Gupta, Luis Lozano,
clang-built-linux, Nathan Chancellor, Russell King,
Catalin Marinas, James Morris, Serge E. Hallyn, Arnd Bergmann,
Masahiro Yamada, Kees Cook, Ard Biesheuvel, Andreas Färber,
Ingo Molnar, Marc Zyngier, Andrew Morton, Mike Rapoport,
Mark Rutland, David Brazdil, James Morse, Linux ARM,
Linux Kernel Mailing List, linux-security-module
From: Linus Walleij
> Sent: 03 March 2021 15:19
>
> On Tue, Feb 23, 2021 at 11:05 AM Will Deacon <will@kernel.org> wrote:
> > On Mon, Feb 22, 2021 at 01:50:06PM -0800, Jian Cai wrote:
> > > I am not sure if there are any plans to protect assembly code and I
> > > will leave it to the Arm folks since they know a whole lot better. But
> > > even without that part, we should still have better protection,
> > > especially when overhead does not look too bad: I did some preliminary
> > > experiments on ChromeOS, code size of vmlinux increased 3%, and there
> > > were no noticeable changes to run-time performance of the benchmarks I
> > > used.
> >
> > If the mitigation is required, I'm not sure I see a lot of point in only
> > doing a half-baked job of it. It feels a bit like a box-ticking exercise,
> > in which case any overhead is too much.
>
> I wrote some suggestions on follow-ups in my reply, and I can
> help out doing some of the patches, I think.
>
> Since ARM32 RET is mov pc, <>
> git grep 'mov.*pc,' | wc -l gives 93 sites in arch/arm.
> I suppose these need to come out:
>
> mov pc, lr
> dsb(nsh);
> isb();
Won't that go horribly wrong for conditional returns?
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply [flat|nested] 58+ messages in thread
* RE: [PATCH v4] ARM: Implement SLS mitigation
@ 2021-03-03 15:29 ` David Laight
0 siblings, 0 replies; 58+ messages in thread
From: David Laight @ 2021-03-03 15:29 UTC (permalink / raw)
To: 'Linus Walleij', Will Deacon
Cc: Jian Cai, Nick Desaulniers, Manoj Gupta, Luis Lozano,
clang-built-linux, Nathan Chancellor, Russell King,
Catalin Marinas, James Morris, Serge E. Hallyn, Arnd Bergmann,
Masahiro Yamada, Kees Cook, Ard Biesheuvel, Andreas Färber,
Ingo Molnar, Marc Zyngier, Andrew Morton, Mike Rapoport,
Mark Rutland, David Brazdil, James Morse, Linux ARM,
Linux Kernel Mailing List, linux-security-module
From: Linus Walleij
> Sent: 03 March 2021 15:19
>
> On Tue, Feb 23, 2021 at 11:05 AM Will Deacon <will@kernel.org> wrote:
> > On Mon, Feb 22, 2021 at 01:50:06PM -0800, Jian Cai wrote:
> > > I am not sure if there are any plans to protect assembly code and I
> > > will leave it to the Arm folks since they know a whole lot better. But
> > > even without that part, we should still have better protection,
> > > especially when overhead does not look too bad: I did some preliminary
> > > experiments on ChromeOS, code size of vmlinux increased 3%, and there
> > > were no noticeable changes to run-time performance of the benchmarks I
> > > used.
> >
> > If the mitigation is required, I'm not sure I see a lot of point in only
> > doing a half-baked job of it. It feels a bit like a box-ticking exercise,
> > in which case any overhead is too much.
>
> I wrote some suggestions on follow-ups in my reply, and I can
> help out doing some of the patches, I think.
>
> Since ARM32 RET is mov pc, <>
> git grep 'mov.*pc,' | wc -l gives 93 sites in arch/arm.
> I suppose these need to come out:
>
> mov pc, lr
> dsb(nsh);
> isb();
Won't that go horribly wrong for conditional returns?
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v4] ARM: Implement SLS mitigation
2021-03-03 15:29 ` David Laight
@ 2021-03-03 15:31 ` Linus Walleij
-1 siblings, 0 replies; 58+ messages in thread
From: Linus Walleij @ 2021-03-03 15:31 UTC (permalink / raw)
To: David Laight
Cc: Will Deacon, Jian Cai, Nick Desaulniers, Manoj Gupta,
Luis Lozano, clang-built-linux, Nathan Chancellor, Russell King,
Catalin Marinas, James Morris, Serge E. Hallyn, Arnd Bergmann,
Masahiro Yamada, Kees Cook, Ard Biesheuvel, Andreas Färber,
Ingo Molnar, Marc Zyngier, Andrew Morton, Mike Rapoport,
Mark Rutland, David Brazdil, James Morse, Linux ARM,
Linux Kernel Mailing List, linux-security-module
On Wed, Mar 3, 2021 at 4:29 PM David Laight <David.Laight@aculab.com> wrote:
> > On Tue, Feb 23, 2021 at 11:05 AM Will Deacon <will@kernel.org> wrote:
> > I wrote some suggestions on follow-ups in my reply, and I can
> > help out doing some of the patches, I think.
> >
> > Since ARM32 RET is mov pc, <>
> > git grep 'mov.*pc,' | wc -l gives 93 sites in arch/arm.
> > I suppose these need to come out:
> >
> > mov pc, lr
> > dsb(nsh);
> > isb();
>
> Won't that go horribly wrong for conditional returns?
It will so I would not insert it after those. It has to be
on a case-by-base basis, I am not planning any
search and replace operations.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v4] ARM: Implement SLS mitigation
@ 2021-03-03 15:31 ` Linus Walleij
0 siblings, 0 replies; 58+ messages in thread
From: Linus Walleij @ 2021-03-03 15:31 UTC (permalink / raw)
To: David Laight
Cc: Will Deacon, Jian Cai, Nick Desaulniers, Manoj Gupta,
Luis Lozano, clang-built-linux, Nathan Chancellor, Russell King,
Catalin Marinas, James Morris, Serge E. Hallyn, Arnd Bergmann,
Masahiro Yamada, Kees Cook, Ard Biesheuvel, Andreas Färber,
Ingo Molnar, Marc Zyngier, Andrew Morton, Mike Rapoport,
Mark Rutland, David Brazdil, James Morse, Linux ARM,
Linux Kernel Mailing List, linux-security-module
On Wed, Mar 3, 2021 at 4:29 PM David Laight <David.Laight@aculab.com> wrote:
> > On Tue, Feb 23, 2021 at 11:05 AM Will Deacon <will@kernel.org> wrote:
> > I wrote some suggestions on follow-ups in my reply, and I can
> > help out doing some of the patches, I think.
> >
> > Since ARM32 RET is mov pc, <>
> > git grep 'mov.*pc,' | wc -l gives 93 sites in arch/arm.
> > I suppose these need to come out:
> >
> > mov pc, lr
> > dsb(nsh);
> > isb();
>
> Won't that go horribly wrong for conditional returns?
It will so I would not insert it after those. It has to be
on a case-by-base basis, I am not planning any
search and replace operations.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v5] ARM: Implement SLS mitigation
2021-02-19 23:08 ` Jian Cai
@ 2021-02-23 2:31 ` Jian Cai
-1 siblings, 0 replies; 58+ messages in thread
From: Jian Cai @ 2021-02-23 2:31 UTC (permalink / raw)
Cc: ndesaulniers, manojgupta, llozano, clang-built-linux, Jian Cai,
Nathan Chancellor, David Laight, Will Deacon, Russell King,
Russell King, Catalin Marinas, James Morris, Serge E. Hallyn,
Arnd Bergmann, Masahiro Yamada, Krzysztof Kozlowski,
Ard Biesheuvel, Kees Cook, Andreas Färber, Ingo Molnar,
Fangrui Song, Marc Zyngier, Mike Rapoport, Andrew Morton,
Mark Rutland, David Brazdil, James Morse, linux-arm-kernel,
linux-kernel, linux-security-module
This patch adds CONFIG_HARDEN_SLS_ALL that can be used to turn on
-mharden-sls=all, which mitigates the straight-line speculation
vulnerability, speculative execution of the instruction following some
unconditional jumps. Notice -mharden-sls= has other options as below,
and this config turns on the strongest option.
all: enable all mitigations against Straight Line Speculation that are implemented.
none: disable all mitigations against Straight Line Speculation.
retbr: enable the mitigation against Straight Line Speculation for RET and BR instructions.
blr: enable the mitigation against Straight Line Speculation for BLR instructions.
Links:
https://reviews.llvm.org/D93221
https://reviews.llvm.org/D81404
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/frequently-asked-questions#SLS2
Suggested-by: Manoj Gupta <manojgupta@google.com>
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Suggested-by: Nathan Chancellor <nathan@kernel.org>
Suggested-by: David Laight <David.Laight@aculab.com>
Suggested-by: Will Deacon <will@kernel.org>
Suggested-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Jian Cai <jiancai@google.com>
---
Changes v4->v5:
Removed "default n" and made the description target indepdent in
Kconfig.hardening.
arch/arm/Makefile | 4 ++++
arch/arm/include/asm/vmlinux.lds.h | 4 ++++
arch/arm/kernel/vmlinux.lds.S | 1 +
arch/arm64/Makefile | 4 ++++
arch/arm64/kernel/vmlinux.lds.S | 5 +++++
security/Kconfig.hardening | 10 ++++++++++
6 files changed, 28 insertions(+)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 4aaec9599e8a..11d89ef32da9 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -48,6 +48,10 @@ CHECKFLAGS += -D__ARMEL__
KBUILD_LDFLAGS += -EL
endif
+ifeq ($(CONFIG_HARDEN_SLS_ALL), y)
+KBUILD_CFLAGS += -mharden-sls=all
+endif
+
#
# The Scalar Replacement of Aggregates (SRA) optimization pass in GCC 4.9 and
# later may result in code being generated that handles signed short and signed
diff --git a/arch/arm/include/asm/vmlinux.lds.h b/arch/arm/include/asm/vmlinux.lds.h
index 4a91428c324d..c7f9717511ca 100644
--- a/arch/arm/include/asm/vmlinux.lds.h
+++ b/arch/arm/include/asm/vmlinux.lds.h
@@ -145,3 +145,7 @@
__edtcm_data = .; \
} \
. = __dtcm_start + SIZEOF(.data_dtcm);
+
+#define SLS_TEXT \
+ ALIGN_FUNCTION(); \
+ *(.text.__llvm_slsblr_thunk_*)
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index f7f4620d59c3..e71f2bc97bae 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -63,6 +63,7 @@ SECTIONS
.text : { /* Real text segment */
_stext = .; /* Text and read-only data */
ARM_TEXT
+ SLS_TEXT
}
#ifdef CONFIG_DEBUG_ALIGN_RODATA
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 90309208bb28..ca7299b356a9 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -34,6 +34,10 @@ $(warning LSE atomics not supported by binutils)
endif
endif
+ifeq ($(CONFIG_HARDEN_SLS_ALL), y)
+KBUILD_CFLAGS += -mharden-sls=all
+endif
+
cc_has_k_constraint := $(call try-run,echo \
'int main(void) { \
asm volatile("and w0, w0, %w0" :: "K" (4294967295)); \
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 4c0b0c89ad59..f8912e42ffcd 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -93,6 +93,10 @@ jiffies = jiffies_64;
#define TRAMP_TEXT
#endif
+#define SLS_TEXT \
+ ALIGN_FUNCTION(); \
+ *(.text.__llvm_slsblr_thunk_*)
+
/*
* The size of the PE/COFF section that covers the kernel image, which
* runs from _stext to _edata, must be a round multiple of the PE/COFF
@@ -144,6 +148,7 @@ SECTIONS
HIBERNATE_TEXT
TRAMP_TEXT
*(.fixup)
+ SLS_TEXT
*(.gnu.warning)
. = ALIGN(16);
*(.got) /* Global offset table */
diff --git a/security/Kconfig.hardening b/security/Kconfig.hardening
index 269967c4fc1b..146b75a79d9e 100644
--- a/security/Kconfig.hardening
+++ b/security/Kconfig.hardening
@@ -121,6 +121,16 @@ choice
endchoice
+config HARDEN_SLS_ALL
+ bool "enable SLS vulnerability hardening"
+ default n
+ depends on $(cc-option,-mharden-sls=all)
+ help
+ Enables straight-line speculation vulnerability hardening on ARM and ARM64
+ architectures. It inserts speculation barrier sequences (SB or DSB+ISB
+ depending on the target architecture) after RET and BR, and replacing
+ BLR with BL+BR sequence.
+
config GCC_PLUGIN_STRUCTLEAK_VERBOSE
bool "Report forcefully initialized variables"
depends on GCC_PLUGIN_STRUCTLEAK
--
2.30.0.617.g56c4b15f3c-goog
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v5] ARM: Implement SLS mitigation
@ 2021-02-23 2:31 ` Jian Cai
0 siblings, 0 replies; 58+ messages in thread
From: Jian Cai @ 2021-02-23 2:31 UTC (permalink / raw)
Cc: Mark Rutland, Catalin Marinas, James Morris, manojgupta,
Will Deacon, Ingo Molnar, Fangrui Song, Marc Zyngier,
Masahiro Yamada, Russell King, Krzysztof Kozlowski,
Ard Biesheuvel, clang-built-linux, llozano, David Brazdil,
Serge E. Hallyn, Kees Cook, Arnd Bergmann, Jian Cai,
Nathan Chancellor, Russell King, linux-arm-kernel, ndesaulniers,
linux-kernel, linux-security-module, David Laight, James Morse,
Andrew Morton, Andreas Färber, Mike Rapoport
This patch adds CONFIG_HARDEN_SLS_ALL that can be used to turn on
-mharden-sls=all, which mitigates the straight-line speculation
vulnerability, speculative execution of the instruction following some
unconditional jumps. Notice -mharden-sls= has other options as below,
and this config turns on the strongest option.
all: enable all mitigations against Straight Line Speculation that are implemented.
none: disable all mitigations against Straight Line Speculation.
retbr: enable the mitigation against Straight Line Speculation for RET and BR instructions.
blr: enable the mitigation against Straight Line Speculation for BLR instructions.
Links:
https://reviews.llvm.org/D93221
https://reviews.llvm.org/D81404
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/frequently-asked-questions#SLS2
Suggested-by: Manoj Gupta <manojgupta@google.com>
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Suggested-by: Nathan Chancellor <nathan@kernel.org>
Suggested-by: David Laight <David.Laight@aculab.com>
Suggested-by: Will Deacon <will@kernel.org>
Suggested-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Jian Cai <jiancai@google.com>
---
Changes v4->v5:
Removed "default n" and made the description target indepdent in
Kconfig.hardening.
arch/arm/Makefile | 4 ++++
arch/arm/include/asm/vmlinux.lds.h | 4 ++++
arch/arm/kernel/vmlinux.lds.S | 1 +
arch/arm64/Makefile | 4 ++++
arch/arm64/kernel/vmlinux.lds.S | 5 +++++
security/Kconfig.hardening | 10 ++++++++++
6 files changed, 28 insertions(+)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 4aaec9599e8a..11d89ef32da9 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -48,6 +48,10 @@ CHECKFLAGS += -D__ARMEL__
KBUILD_LDFLAGS += -EL
endif
+ifeq ($(CONFIG_HARDEN_SLS_ALL), y)
+KBUILD_CFLAGS += -mharden-sls=all
+endif
+
#
# The Scalar Replacement of Aggregates (SRA) optimization pass in GCC 4.9 and
# later may result in code being generated that handles signed short and signed
diff --git a/arch/arm/include/asm/vmlinux.lds.h b/arch/arm/include/asm/vmlinux.lds.h
index 4a91428c324d..c7f9717511ca 100644
--- a/arch/arm/include/asm/vmlinux.lds.h
+++ b/arch/arm/include/asm/vmlinux.lds.h
@@ -145,3 +145,7 @@
__edtcm_data = .; \
} \
. = __dtcm_start + SIZEOF(.data_dtcm);
+
+#define SLS_TEXT \
+ ALIGN_FUNCTION(); \
+ *(.text.__llvm_slsblr_thunk_*)
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index f7f4620d59c3..e71f2bc97bae 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -63,6 +63,7 @@ SECTIONS
.text : { /* Real text segment */
_stext = .; /* Text and read-only data */
ARM_TEXT
+ SLS_TEXT
}
#ifdef CONFIG_DEBUG_ALIGN_RODATA
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 90309208bb28..ca7299b356a9 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -34,6 +34,10 @@ $(warning LSE atomics not supported by binutils)
endif
endif
+ifeq ($(CONFIG_HARDEN_SLS_ALL), y)
+KBUILD_CFLAGS += -mharden-sls=all
+endif
+
cc_has_k_constraint := $(call try-run,echo \
'int main(void) { \
asm volatile("and w0, w0, %w0" :: "K" (4294967295)); \
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 4c0b0c89ad59..f8912e42ffcd 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -93,6 +93,10 @@ jiffies = jiffies_64;
#define TRAMP_TEXT
#endif
+#define SLS_TEXT \
+ ALIGN_FUNCTION(); \
+ *(.text.__llvm_slsblr_thunk_*)
+
/*
* The size of the PE/COFF section that covers the kernel image, which
* runs from _stext to _edata, must be a round multiple of the PE/COFF
@@ -144,6 +148,7 @@ SECTIONS
HIBERNATE_TEXT
TRAMP_TEXT
*(.fixup)
+ SLS_TEXT
*(.gnu.warning)
. = ALIGN(16);
*(.got) /* Global offset table */
diff --git a/security/Kconfig.hardening b/security/Kconfig.hardening
index 269967c4fc1b..146b75a79d9e 100644
--- a/security/Kconfig.hardening
+++ b/security/Kconfig.hardening
@@ -121,6 +121,16 @@ choice
endchoice
+config HARDEN_SLS_ALL
+ bool "enable SLS vulnerability hardening"
+ default n
+ depends on $(cc-option,-mharden-sls=all)
+ help
+ Enables straight-line speculation vulnerability hardening on ARM and ARM64
+ architectures. It inserts speculation barrier sequences (SB or DSB+ISB
+ depending on the target architecture) after RET and BR, and replacing
+ BLR with BL+BR sequence.
+
config GCC_PLUGIN_STRUCTLEAK_VERBOSE
bool "Report forcefully initialized variables"
depends on GCC_PLUGIN_STRUCTLEAK
--
2.30.0.617.g56c4b15f3c-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v5] ARM: Implement SLS mitigation
2021-02-23 2:31 ` Jian Cai
@ 2021-02-23 2:35 ` Jian Cai
-1 siblings, 0 replies; 58+ messages in thread
From: Jian Cai @ 2021-02-23 2:35 UTC (permalink / raw)
Cc: ndesaulniers, manojgupta, llozano, clang-built-linux, Jian Cai,
Nathan Chancellor, David Laight, Will Deacon, Russell King,
Russell King, Catalin Marinas, James Morris, Serge E. Hallyn,
Arnd Bergmann, Masahiro Yamada, Krzysztof Kozlowski,
Marc Zyngier, Kees Cook, Andreas Färber, Ard Biesheuvel,
Ingo Molnar, Andrew Morton, Mike Rapoport, Mark Rutland,
David Brazdil, James Morse, linux-arm-kernel, linux-kernel,
linux-security-module
This patch adds CONFIG_HARDEN_SLS_ALL that can be used to turn on
-mharden-sls=all, which mitigates the straight-line speculation
vulnerability, speculative execution of the instruction following some
unconditional jumps. Notice -mharden-sls= has other options as below,
and this config turns on the strongest option.
all: enable all mitigations against Straight Line Speculation that are implemented.
none: disable all mitigations against Straight Line Speculation.
retbr: enable the mitigation against Straight Line Speculation for RET and BR instructions.
blr: enable the mitigation against Straight Line Speculation for BLR instructions.
Links:
https://reviews.llvm.org/D93221
https://reviews.llvm.org/D81404
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/frequently-asked-questions#SLS2
Suggested-by: Manoj Gupta <manojgupta@google.com>
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Suggested-by: Nathan Chancellor <nathan@kernel.org>
Suggested-by: David Laight <David.Laight@aculab.com>
Suggested-by: Will Deacon <will@kernel.org>
Suggested-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Jian Cai <jiancai@google.com>
---
Changes v4->v5:
Removed "default n" and made the description target indepdent in
Kconfig.hardening. Please ignore my last email, it did not include the
changes.
arch/arm/Makefile | 4 ++++
arch/arm/include/asm/vmlinux.lds.h | 4 ++++
arch/arm/kernel/vmlinux.lds.S | 1 +
arch/arm64/Makefile | 4 ++++
arch/arm64/kernel/vmlinux.lds.S | 5 +++++
security/Kconfig.hardening | 8 ++++++++
6 files changed, 26 insertions(+)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 4aaec9599e8a..11d89ef32da9 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -48,6 +48,10 @@ CHECKFLAGS += -D__ARMEL__
KBUILD_LDFLAGS += -EL
endif
+ifeq ($(CONFIG_HARDEN_SLS_ALL), y)
+KBUILD_CFLAGS += -mharden-sls=all
+endif
+
#
# The Scalar Replacement of Aggregates (SRA) optimization pass in GCC 4.9 and
# later may result in code being generated that handles signed short and signed
diff --git a/arch/arm/include/asm/vmlinux.lds.h b/arch/arm/include/asm/vmlinux.lds.h
index 4a91428c324d..c7f9717511ca 100644
--- a/arch/arm/include/asm/vmlinux.lds.h
+++ b/arch/arm/include/asm/vmlinux.lds.h
@@ -145,3 +145,7 @@
__edtcm_data = .; \
} \
. = __dtcm_start + SIZEOF(.data_dtcm);
+
+#define SLS_TEXT \
+ ALIGN_FUNCTION(); \
+ *(.text.__llvm_slsblr_thunk_*)
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index f7f4620d59c3..e71f2bc97bae 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -63,6 +63,7 @@ SECTIONS
.text : { /* Real text segment */
_stext = .; /* Text and read-only data */
ARM_TEXT
+ SLS_TEXT
}
#ifdef CONFIG_DEBUG_ALIGN_RODATA
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 90309208bb28..ca7299b356a9 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -34,6 +34,10 @@ $(warning LSE atomics not supported by binutils)
endif
endif
+ifeq ($(CONFIG_HARDEN_SLS_ALL), y)
+KBUILD_CFLAGS += -mharden-sls=all
+endif
+
cc_has_k_constraint := $(call try-run,echo \
'int main(void) { \
asm volatile("and w0, w0, %w0" :: "K" (4294967295)); \
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 4c0b0c89ad59..f8912e42ffcd 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -93,6 +93,10 @@ jiffies = jiffies_64;
#define TRAMP_TEXT
#endif
+#define SLS_TEXT \
+ ALIGN_FUNCTION(); \
+ *(.text.__llvm_slsblr_thunk_*)
+
/*
* The size of the PE/COFF section that covers the kernel image, which
* runs from _stext to _edata, must be a round multiple of the PE/COFF
@@ -144,6 +148,7 @@ SECTIONS
HIBERNATE_TEXT
TRAMP_TEXT
*(.fixup)
+ SLS_TEXT
*(.gnu.warning)
. = ALIGN(16);
*(.got) /* Global offset table */
diff --git a/security/Kconfig.hardening b/security/Kconfig.hardening
index 269967c4fc1b..db76ad732c14 100644
--- a/security/Kconfig.hardening
+++ b/security/Kconfig.hardening
@@ -121,6 +121,14 @@ choice
endchoice
+config HARDEN_SLS_ALL
+ bool "enable SLS vulnerability hardening"
+ depends on $(cc-option,-mharden-sls=all)
+ help
+ Enables straight-line speculation vulnerability hardening. This inserts
+ speculation barrier instruction sequences after certain unconditional jumps
+ to prevent speculative execution past those barriers.
+
config GCC_PLUGIN_STRUCTLEAK_VERBOSE
bool "Report forcefully initialized variables"
depends on GCC_PLUGIN_STRUCTLEAK
--
2.30.0.617.g56c4b15f3c-goog
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v5] ARM: Implement SLS mitigation
@ 2021-02-23 2:35 ` Jian Cai
0 siblings, 0 replies; 58+ messages in thread
From: Jian Cai @ 2021-02-23 2:35 UTC (permalink / raw)
Cc: Mark Rutland, Catalin Marinas, James Morris, manojgupta,
Will Deacon, Ingo Molnar, Marc Zyngier, Masahiro Yamada,
Russell King, Krzysztof Kozlowski, Ard Biesheuvel,
clang-built-linux, llozano, David Brazdil, Serge E. Hallyn,
Kees Cook, Arnd Bergmann, Jian Cai, Nathan Chancellor,
Russell King, linux-arm-kernel, ndesaulniers, linux-kernel,
linux-security-module, David Laight, James Morse, Andrew Morton,
Andreas Färber, Mike Rapoport
This patch adds CONFIG_HARDEN_SLS_ALL that can be used to turn on
-mharden-sls=all, which mitigates the straight-line speculation
vulnerability, speculative execution of the instruction following some
unconditional jumps. Notice -mharden-sls= has other options as below,
and this config turns on the strongest option.
all: enable all mitigations against Straight Line Speculation that are implemented.
none: disable all mitigations against Straight Line Speculation.
retbr: enable the mitigation against Straight Line Speculation for RET and BR instructions.
blr: enable the mitigation against Straight Line Speculation for BLR instructions.
Links:
https://reviews.llvm.org/D93221
https://reviews.llvm.org/D81404
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/frequently-asked-questions#SLS2
Suggested-by: Manoj Gupta <manojgupta@google.com>
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Suggested-by: Nathan Chancellor <nathan@kernel.org>
Suggested-by: David Laight <David.Laight@aculab.com>
Suggested-by: Will Deacon <will@kernel.org>
Suggested-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Jian Cai <jiancai@google.com>
---
Changes v4->v5:
Removed "default n" and made the description target indepdent in
Kconfig.hardening. Please ignore my last email, it did not include the
changes.
arch/arm/Makefile | 4 ++++
arch/arm/include/asm/vmlinux.lds.h | 4 ++++
arch/arm/kernel/vmlinux.lds.S | 1 +
arch/arm64/Makefile | 4 ++++
arch/arm64/kernel/vmlinux.lds.S | 5 +++++
security/Kconfig.hardening | 8 ++++++++
6 files changed, 26 insertions(+)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 4aaec9599e8a..11d89ef32da9 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -48,6 +48,10 @@ CHECKFLAGS += -D__ARMEL__
KBUILD_LDFLAGS += -EL
endif
+ifeq ($(CONFIG_HARDEN_SLS_ALL), y)
+KBUILD_CFLAGS += -mharden-sls=all
+endif
+
#
# The Scalar Replacement of Aggregates (SRA) optimization pass in GCC 4.9 and
# later may result in code being generated that handles signed short and signed
diff --git a/arch/arm/include/asm/vmlinux.lds.h b/arch/arm/include/asm/vmlinux.lds.h
index 4a91428c324d..c7f9717511ca 100644
--- a/arch/arm/include/asm/vmlinux.lds.h
+++ b/arch/arm/include/asm/vmlinux.lds.h
@@ -145,3 +145,7 @@
__edtcm_data = .; \
} \
. = __dtcm_start + SIZEOF(.data_dtcm);
+
+#define SLS_TEXT \
+ ALIGN_FUNCTION(); \
+ *(.text.__llvm_slsblr_thunk_*)
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index f7f4620d59c3..e71f2bc97bae 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -63,6 +63,7 @@ SECTIONS
.text : { /* Real text segment */
_stext = .; /* Text and read-only data */
ARM_TEXT
+ SLS_TEXT
}
#ifdef CONFIG_DEBUG_ALIGN_RODATA
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 90309208bb28..ca7299b356a9 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -34,6 +34,10 @@ $(warning LSE atomics not supported by binutils)
endif
endif
+ifeq ($(CONFIG_HARDEN_SLS_ALL), y)
+KBUILD_CFLAGS += -mharden-sls=all
+endif
+
cc_has_k_constraint := $(call try-run,echo \
'int main(void) { \
asm volatile("and w0, w0, %w0" :: "K" (4294967295)); \
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 4c0b0c89ad59..f8912e42ffcd 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -93,6 +93,10 @@ jiffies = jiffies_64;
#define TRAMP_TEXT
#endif
+#define SLS_TEXT \
+ ALIGN_FUNCTION(); \
+ *(.text.__llvm_slsblr_thunk_*)
+
/*
* The size of the PE/COFF section that covers the kernel image, which
* runs from _stext to _edata, must be a round multiple of the PE/COFF
@@ -144,6 +148,7 @@ SECTIONS
HIBERNATE_TEXT
TRAMP_TEXT
*(.fixup)
+ SLS_TEXT
*(.gnu.warning)
. = ALIGN(16);
*(.got) /* Global offset table */
diff --git a/security/Kconfig.hardening b/security/Kconfig.hardening
index 269967c4fc1b..db76ad732c14 100644
--- a/security/Kconfig.hardening
+++ b/security/Kconfig.hardening
@@ -121,6 +121,14 @@ choice
endchoice
+config HARDEN_SLS_ALL
+ bool "enable SLS vulnerability hardening"
+ depends on $(cc-option,-mharden-sls=all)
+ help
+ Enables straight-line speculation vulnerability hardening. This inserts
+ speculation barrier instruction sequences after certain unconditional jumps
+ to prevent speculative execution past those barriers.
+
config GCC_PLUGIN_STRUCTLEAK_VERBOSE
bool "Report forcefully initialized variables"
depends on GCC_PLUGIN_STRUCTLEAK
--
2.30.0.617.g56c4b15f3c-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 58+ messages in thread
* Re: [PATCH v5] ARM: Implement SLS mitigation
2021-02-23 2:35 ` Jian Cai
@ 2021-03-03 15:04 ` Linus Walleij
-1 siblings, 0 replies; 58+ messages in thread
From: Linus Walleij @ 2021-03-03 15:04 UTC (permalink / raw)
To: Jian Cai
Cc: Nick Desaulniers, manojgupta, llozano, clang-built-linux,
Nathan Chancellor, David Laight, Will Deacon, Russell King,
Russell King, Catalin Marinas, James Morris, Serge E. Hallyn,
Arnd Bergmann, Masahiro Yamada, Krzysztof Kozlowski,
Marc Zyngier, Kees Cook, Andreas Färber, Ard Biesheuvel,
Ingo Molnar, Andrew Morton, Mike Rapoport, Mark Rutland,
David Brazdil, James Morse, Linux ARM, linux-kernel,
linux-security-module
On Tue, Feb 23, 2021 at 3:36 AM Jian Cai <jiancai@google.com> wrote:
> This patch adds CONFIG_HARDEN_SLS_ALL that can be used to turn on
> -mharden-sls=all, which mitigates the straight-line speculation
> vulnerability, speculative execution of the instruction following some
> unconditional jumps. Notice -mharden-sls= has other options as below,
> and this config turns on the strongest option.
>
> all: enable all mitigations against Straight Line Speculation that are implemented.
> none: disable all mitigations against Straight Line Speculation.
> retbr: enable the mitigation against Straight Line Speculation for RET and BR instructions.
> blr: enable the mitigation against Straight Line Speculation for BLR instructions.
I heard about compiler protection for this, so nice to see it happening!
Would you happen to know if there is any plan to do the same for GCC?
I know you folks at Google like LLVM, but if you know let us know.
> +config HARDEN_SLS_ALL
> + bool "enable SLS vulnerability hardening"
I would go in and also edit arch/arm/mm/Kconfig under:
config HARDEN_BRANCH_PREDICTOR add
select HARDEN_SLS_ALL
Because if the user wants hardening for branch prediction
in general then the user certainly wants this as well, if
available. The help text for that option literally says:
"This config option will take CPU-specific actions to harden
the branch predictor against aliasing attacks and may rely on
specific instruction sequences or control bits being set by
the system firmware."
Notice this only turns on for CPUs with CPU_SPECTRE
defined which makes sense. Also it is default y which fulfils
Will's request that it be turned on by default where
applicable. Notably it will not be turned on for pre-v7 silicon
which would be unhelpful as they don't suffer from
these bugs.
Reading Kristofs compiler patch here:
https://reviews.llvm.org/rG195f44278c4361a4a32377a98a1e3a15203d3647
I take it that for affected CPUs we should also patch all assembly
in the kernel containing a RET, BR or BLR with
DSB SYS followed by ISB?
I suppose we would also need to look for any mov PC, <>
code...
I guess we can invent a "SB" macro to mimic what Aarch64 is
doing so the code is easy to read. (Thinking aloud.)
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v5] ARM: Implement SLS mitigation
@ 2021-03-03 15:04 ` Linus Walleij
0 siblings, 0 replies; 58+ messages in thread
From: Linus Walleij @ 2021-03-03 15:04 UTC (permalink / raw)
To: Jian Cai
Cc: Nick Desaulniers, manojgupta, llozano, clang-built-linux,
Nathan Chancellor, David Laight, Will Deacon, Russell King,
Russell King, Catalin Marinas, James Morris, Serge E. Hallyn,
Arnd Bergmann, Masahiro Yamada, Krzysztof Kozlowski,
Marc Zyngier, Kees Cook, Andreas Färber, Ard Biesheuvel,
Ingo Molnar, Andrew Morton, Mike Rapoport, Mark Rutland,
David Brazdil, James Morse, Linux ARM, linux-kernel,
linux-security-module
On Tue, Feb 23, 2021 at 3:36 AM Jian Cai <jiancai@google.com> wrote:
> This patch adds CONFIG_HARDEN_SLS_ALL that can be used to turn on
> -mharden-sls=all, which mitigates the straight-line speculation
> vulnerability, speculative execution of the instruction following some
> unconditional jumps. Notice -mharden-sls= has other options as below,
> and this config turns on the strongest option.
>
> all: enable all mitigations against Straight Line Speculation that are implemented.
> none: disable all mitigations against Straight Line Speculation.
> retbr: enable the mitigation against Straight Line Speculation for RET and BR instructions.
> blr: enable the mitigation against Straight Line Speculation for BLR instructions.
I heard about compiler protection for this, so nice to see it happening!
Would you happen to know if there is any plan to do the same for GCC?
I know you folks at Google like LLVM, but if you know let us know.
> +config HARDEN_SLS_ALL
> + bool "enable SLS vulnerability hardening"
I would go in and also edit arch/arm/mm/Kconfig under:
config HARDEN_BRANCH_PREDICTOR add
select HARDEN_SLS_ALL
Because if the user wants hardening for branch prediction
in general then the user certainly wants this as well, if
available. The help text for that option literally says:
"This config option will take CPU-specific actions to harden
the branch predictor against aliasing attacks and may rely on
specific instruction sequences or control bits being set by
the system firmware."
Notice this only turns on for CPUs with CPU_SPECTRE
defined which makes sense. Also it is default y which fulfils
Will's request that it be turned on by default where
applicable. Notably it will not be turned on for pre-v7 silicon
which would be unhelpful as they don't suffer from
these bugs.
Reading Kristofs compiler patch here:
https://reviews.llvm.org/rG195f44278c4361a4a32377a98a1e3a15203d3647
I take it that for affected CPUs we should also patch all assembly
in the kernel containing a RET, BR or BLR with
DSB SYS followed by ISB?
I suppose we would also need to look for any mov PC, <>
code...
I guess we can invent a "SB" macro to mimic what Aarch64 is
doing so the code is easy to read. (Thinking aloud.)
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v5] ARM: Implement SLS mitigation
2021-03-03 15:04 ` Linus Walleij
@ 2021-03-04 23:22 ` Jian Cai
-1 siblings, 0 replies; 58+ messages in thread
From: Jian Cai @ 2021-03-04 23:22 UTC (permalink / raw)
To: Linus Walleij
Cc: Nick Desaulniers, Manoj Gupta, Luis Lozano, clang-built-linux,
Nathan Chancellor, David Laight, Will Deacon, Russell King,
Russell King, Catalin Marinas, James Morris, Serge E. Hallyn,
Arnd Bergmann, Masahiro Yamada, Krzysztof Kozlowski,
Marc Zyngier, Kees Cook, Andreas Färber, Ard Biesheuvel,
Ingo Molnar, Andrew Morton, Mike Rapoport, Mark Rutland,
David Brazdil, James Morse, Linux ARM, linux-kernel,
linux-security-module
On Wed, Mar 3, 2021 at 7:04 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Tue, Feb 23, 2021 at 3:36 AM Jian Cai <jiancai@google.com> wrote:
>
> > This patch adds CONFIG_HARDEN_SLS_ALL that can be used to turn on
> > -mharden-sls=all, which mitigates the straight-line speculation
> > vulnerability, speculative execution of the instruction following some
> > unconditional jumps. Notice -mharden-sls= has other options as below,
> > and this config turns on the strongest option.
> >
> > all: enable all mitigations against Straight Line Speculation that are implemented.
> > none: disable all mitigations against Straight Line Speculation.
> > retbr: enable the mitigation against Straight Line Speculation for RET and BR instructions.
> > blr: enable the mitigation against Straight Line Speculation for BLR instructions.
>
> I heard about compiler protection for this, so nice to see it happening!
>
> Would you happen to know if there is any plan to do the same for GCC?
> I know you folks at Google like LLVM, but if you know let us know.
I think gcc also has these options.
https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html
>
> > +config HARDEN_SLS_ALL
> > + bool "enable SLS vulnerability hardening"
>
> I would go in and also edit arch/arm/mm/Kconfig under:
> config HARDEN_BRANCH_PREDICTOR add
> select HARDEN_SLS_ALL
>
> Because if the user wants hardening for branch prediction
> in general then the user certainly wants this as well, if
> available. The help text for that option literally says:
>
> "This config option will take CPU-specific actions to harden
> the branch predictor against aliasing attacks and may rely on
> specific instruction sequences or control bits being set by
> the system firmware."
>
> Notice this only turns on for CPUs with CPU_SPECTRE
> defined which makes sense. Also it is default y which fulfils
> Will's request that it be turned on by default where
> applicable. Notably it will not be turned on for pre-v7 silicon
> which would be unhelpful as they don't suffer from
> these bugs.
Thanks for the suggestion. I will update the patch.
>
> Reading Kristofs compiler patch here:
> https://reviews.llvm.org/rG195f44278c4361a4a32377a98a1e3a15203d3647
>
> I take it that for affected CPUs we should also patch all assembly
> in the kernel containing a RET, BR or BLR with
> DSB SYS followed by ISB?
>
> I suppose we would also need to look for any mov PC, <>
> code...
>
> I guess we can invent a "SB" macro to mimic what Aarch64 is
> doing so the code is easy to read. (Thinking aloud.)
>
> Yours,
> Linus Walleij
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v5] ARM: Implement SLS mitigation
@ 2021-03-04 23:22 ` Jian Cai
0 siblings, 0 replies; 58+ messages in thread
From: Jian Cai @ 2021-03-04 23:22 UTC (permalink / raw)
To: Linus Walleij
Cc: Nick Desaulniers, Manoj Gupta, Luis Lozano, clang-built-linux,
Nathan Chancellor, David Laight, Will Deacon, Russell King,
Russell King, Catalin Marinas, James Morris, Serge E. Hallyn,
Arnd Bergmann, Masahiro Yamada, Krzysztof Kozlowski,
Marc Zyngier, Kees Cook, Andreas Färber, Ard Biesheuvel,
Ingo Molnar, Andrew Morton, Mike Rapoport, Mark Rutland,
David Brazdil, James Morse, Linux ARM, linux-kernel,
linux-security-module
On Wed, Mar 3, 2021 at 7:04 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Tue, Feb 23, 2021 at 3:36 AM Jian Cai <jiancai@google.com> wrote:
>
> > This patch adds CONFIG_HARDEN_SLS_ALL that can be used to turn on
> > -mharden-sls=all, which mitigates the straight-line speculation
> > vulnerability, speculative execution of the instruction following some
> > unconditional jumps. Notice -mharden-sls= has other options as below,
> > and this config turns on the strongest option.
> >
> > all: enable all mitigations against Straight Line Speculation that are implemented.
> > none: disable all mitigations against Straight Line Speculation.
> > retbr: enable the mitigation against Straight Line Speculation for RET and BR instructions.
> > blr: enable the mitigation against Straight Line Speculation for BLR instructions.
>
> I heard about compiler protection for this, so nice to see it happening!
>
> Would you happen to know if there is any plan to do the same for GCC?
> I know you folks at Google like LLVM, but if you know let us know.
I think gcc also has these options.
https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html
>
> > +config HARDEN_SLS_ALL
> > + bool "enable SLS vulnerability hardening"
>
> I would go in and also edit arch/arm/mm/Kconfig under:
> config HARDEN_BRANCH_PREDICTOR add
> select HARDEN_SLS_ALL
>
> Because if the user wants hardening for branch prediction
> in general then the user certainly wants this as well, if
> available. The help text for that option literally says:
>
> "This config option will take CPU-specific actions to harden
> the branch predictor against aliasing attacks and may rely on
> specific instruction sequences or control bits being set by
> the system firmware."
>
> Notice this only turns on for CPUs with CPU_SPECTRE
> defined which makes sense. Also it is default y which fulfils
> Will's request that it be turned on by default where
> applicable. Notably it will not be turned on for pre-v7 silicon
> which would be unhelpful as they don't suffer from
> these bugs.
Thanks for the suggestion. I will update the patch.
>
> Reading Kristofs compiler patch here:
> https://reviews.llvm.org/rG195f44278c4361a4a32377a98a1e3a15203d3647
>
> I take it that for affected CPUs we should also patch all assembly
> in the kernel containing a RET, BR or BLR with
> DSB SYS followed by ISB?
>
> I suppose we would also need to look for any mov PC, <>
> code...
>
> I guess we can invent a "SB" macro to mimic what Aarch64 is
> doing so the code is easy to read. (Thinking aloud.)
>
> Yours,
> Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v5] ARM: Implement SLS mitigation
2021-03-04 23:22 ` Jian Cai
@ 2021-03-06 12:25 ` Linus Walleij
-1 siblings, 0 replies; 58+ messages in thread
From: Linus Walleij @ 2021-03-06 12:25 UTC (permalink / raw)
To: Jian Cai
Cc: Nick Desaulniers, Manoj Gupta, Luis Lozano, clang-built-linux,
Nathan Chancellor, David Laight, Will Deacon, Russell King,
Russell King, Catalin Marinas, James Morris, Serge E. Hallyn,
Arnd Bergmann, Masahiro Yamada, Krzysztof Kozlowski,
Marc Zyngier, Kees Cook, Andreas Färber, Ard Biesheuvel,
Ingo Molnar, Andrew Morton, Mike Rapoport, Mark Rutland,
David Brazdil, James Morse, Linux ARM, linux-kernel,
linux-security-module
On Fri, Mar 5, 2021 at 12:23 AM Jian Cai <jiancai@google.com> wrote:
> On Wed, Mar 3, 2021 at 7:04 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> >
> > On Tue, Feb 23, 2021 at 3:36 AM Jian Cai <jiancai@google.com> wrote:
> >
> > > This patch adds CONFIG_HARDEN_SLS_ALL that can be used to turn on
> > > -mharden-sls=all, which mitigates the straight-line speculation
> > > vulnerability, speculative execution of the instruction following some
> > > unconditional jumps. Notice -mharden-sls= has other options as below,
> > > and this config turns on the strongest option.
> > >
> > > all: enable all mitigations against Straight Line Speculation that are implemented.
> > > none: disable all mitigations against Straight Line Speculation.
> > > retbr: enable the mitigation against Straight Line Speculation for RET and BR instructions.
> > > blr: enable the mitigation against Straight Line Speculation for BLR instructions.
> >
> > I heard about compiler protection for this, so nice to see it happening!
> >
> > Would you happen to know if there is any plan to do the same for GCC?
> > I know you folks at Google like LLVM, but if you know let us know.
>
> I think gcc also has these options.
> https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html
And how does that work with this part of your patch:
+#define SLS_TEXT \
+ ALIGN_FUNCTION(); \
+ *(.text.__llvm_slsblr_thunk_*)
This does not look compiler agnostic?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v5] ARM: Implement SLS mitigation
@ 2021-03-06 12:25 ` Linus Walleij
0 siblings, 0 replies; 58+ messages in thread
From: Linus Walleij @ 2021-03-06 12:25 UTC (permalink / raw)
To: Jian Cai
Cc: Nick Desaulniers, Manoj Gupta, Luis Lozano, clang-built-linux,
Nathan Chancellor, David Laight, Will Deacon, Russell King,
Russell King, Catalin Marinas, James Morris, Serge E. Hallyn,
Arnd Bergmann, Masahiro Yamada, Krzysztof Kozlowski,
Marc Zyngier, Kees Cook, Andreas Färber, Ard Biesheuvel,
Ingo Molnar, Andrew Morton, Mike Rapoport, Mark Rutland,
David Brazdil, James Morse, Linux ARM, linux-kernel,
linux-security-module
On Fri, Mar 5, 2021 at 12:23 AM Jian Cai <jiancai@google.com> wrote:
> On Wed, Mar 3, 2021 at 7:04 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> >
> > On Tue, Feb 23, 2021 at 3:36 AM Jian Cai <jiancai@google.com> wrote:
> >
> > > This patch adds CONFIG_HARDEN_SLS_ALL that can be used to turn on
> > > -mharden-sls=all, which mitigates the straight-line speculation
> > > vulnerability, speculative execution of the instruction following some
> > > unconditional jumps. Notice -mharden-sls= has other options as below,
> > > and this config turns on the strongest option.
> > >
> > > all: enable all mitigations against Straight Line Speculation that are implemented.
> > > none: disable all mitigations against Straight Line Speculation.
> > > retbr: enable the mitigation against Straight Line Speculation for RET and BR instructions.
> > > blr: enable the mitigation against Straight Line Speculation for BLR instructions.
> >
> > I heard about compiler protection for this, so nice to see it happening!
> >
> > Would you happen to know if there is any plan to do the same for GCC?
> > I know you folks at Google like LLVM, but if you know let us know.
>
> I think gcc also has these options.
> https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html
And how does that work with this part of your patch:
+#define SLS_TEXT \
+ ALIGN_FUNCTION(); \
+ *(.text.__llvm_slsblr_thunk_*)
This does not look compiler agnostic?
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v5] ARM: Implement SLS mitigation
2021-03-06 12:25 ` Linus Walleij
@ 2021-03-10 4:43 ` Jian Cai
-1 siblings, 0 replies; 58+ messages in thread
From: Jian Cai @ 2021-03-10 4:43 UTC (permalink / raw)
To: Linus Walleij
Cc: Nick Desaulniers, Manoj Gupta, Luis Lozano, clang-built-linux,
Nathan Chancellor, David Laight, Will Deacon, Russell King,
Russell King, Catalin Marinas, James Morris, Serge E. Hallyn,
Arnd Bergmann, Masahiro Yamada, Krzysztof Kozlowski,
Marc Zyngier, Kees Cook, Andreas Färber, Ard Biesheuvel,
Ingo Molnar, Andrew Morton, Mike Rapoport, Mark Rutland,
David Brazdil, James Morse, Linux ARM, linux-kernel,
linux-security-module
On Sat, Mar 6, 2021 at 4:25 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Fri, Mar 5, 2021 at 12:23 AM Jian Cai <jiancai@google.com> wrote:
> > On Wed, Mar 3, 2021 at 7:04 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> > >
> > > On Tue, Feb 23, 2021 at 3:36 AM Jian Cai <jiancai@google.com> wrote:
> > >
> > > > This patch adds CONFIG_HARDEN_SLS_ALL that can be used to turn on
> > > > -mharden-sls=all, which mitigates the straight-line speculation
> > > > vulnerability, speculative execution of the instruction following some
> > > > unconditional jumps. Notice -mharden-sls= has other options as below,
> > > > and this config turns on the strongest option.
> > > >
> > > > all: enable all mitigations against Straight Line Speculation that are implemented.
> > > > none: disable all mitigations against Straight Line Speculation.
> > > > retbr: enable the mitigation against Straight Line Speculation for RET and BR instructions.
> > > > blr: enable the mitigation against Straight Line Speculation for BLR instructions.
> > >
> > > I heard about compiler protection for this, so nice to see it happening!
> > >
> > > Would you happen to know if there is any plan to do the same for GCC?
> > > I know you folks at Google like LLVM, but if you know let us know.
> >
> > I think gcc also has these options.
> > https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html
>
> And how does that work with this part of your patch:
>
> +#define SLS_TEXT \
> + ALIGN_FUNCTION(); \
> + *(.text.__llvm_slsblr_thunk_*)
>
> This does not look compiler agnostic?
>
You are right, GCC does generate different oraphan section names. I
will address it in the next version of the patch. Also it seems only
arm64 gcc supports -mharden-sls=* at this moment, arm32 gcc does not
support it yet. I don't know if there is any plan to implement it for
32-bit gcc, but should we patch arm32 linker script preemptively,
assuming the sections will be named with the same pattern like how
clang does so the kernel would not fail to boot when the flag is
implemented?
Thanks,
Jian
> Yours,
> Linus Walleij
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v5] ARM: Implement SLS mitigation
@ 2021-03-10 4:43 ` Jian Cai
0 siblings, 0 replies; 58+ messages in thread
From: Jian Cai @ 2021-03-10 4:43 UTC (permalink / raw)
To: Linus Walleij
Cc: Nick Desaulniers, Manoj Gupta, Luis Lozano, clang-built-linux,
Nathan Chancellor, David Laight, Will Deacon, Russell King,
Russell King, Catalin Marinas, James Morris, Serge E. Hallyn,
Arnd Bergmann, Masahiro Yamada, Krzysztof Kozlowski,
Marc Zyngier, Kees Cook, Andreas Färber, Ard Biesheuvel,
Ingo Molnar, Andrew Morton, Mike Rapoport, Mark Rutland,
David Brazdil, James Morse, Linux ARM, linux-kernel,
linux-security-module
On Sat, Mar 6, 2021 at 4:25 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Fri, Mar 5, 2021 at 12:23 AM Jian Cai <jiancai@google.com> wrote:
> > On Wed, Mar 3, 2021 at 7:04 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> > >
> > > On Tue, Feb 23, 2021 at 3:36 AM Jian Cai <jiancai@google.com> wrote:
> > >
> > > > This patch adds CONFIG_HARDEN_SLS_ALL that can be used to turn on
> > > > -mharden-sls=all, which mitigates the straight-line speculation
> > > > vulnerability, speculative execution of the instruction following some
> > > > unconditional jumps. Notice -mharden-sls= has other options as below,
> > > > and this config turns on the strongest option.
> > > >
> > > > all: enable all mitigations against Straight Line Speculation that are implemented.
> > > > none: disable all mitigations against Straight Line Speculation.
> > > > retbr: enable the mitigation against Straight Line Speculation for RET and BR instructions.
> > > > blr: enable the mitigation against Straight Line Speculation for BLR instructions.
> > >
> > > I heard about compiler protection for this, so nice to see it happening!
> > >
> > > Would you happen to know if there is any plan to do the same for GCC?
> > > I know you folks at Google like LLVM, but if you know let us know.
> >
> > I think gcc also has these options.
> > https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html
>
> And how does that work with this part of your patch:
>
> +#define SLS_TEXT \
> + ALIGN_FUNCTION(); \
> + *(.text.__llvm_slsblr_thunk_*)
>
> This does not look compiler agnostic?
>
You are right, GCC does generate different oraphan section names. I
will address it in the next version of the patch. Also it seems only
arm64 gcc supports -mharden-sls=* at this moment, arm32 gcc does not
support it yet. I don't know if there is any plan to implement it for
32-bit gcc, but should we patch arm32 linker script preemptively,
assuming the sections will be named with the same pattern like how
clang does so the kernel would not fail to boot when the flag is
implemented?
Thanks,
Jian
> Yours,
> Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v5] ARM: Implement SLS mitigation
2021-03-10 4:43 ` Jian Cai
@ 2021-03-22 11:45 ` Linus Walleij
-1 siblings, 0 replies; 58+ messages in thread
From: Linus Walleij @ 2021-03-22 11:45 UTC (permalink / raw)
To: Jian Cai
Cc: Nick Desaulniers, Manoj Gupta, Luis Lozano, clang-built-linux,
Nathan Chancellor, David Laight, Will Deacon, Russell King,
Russell King, Catalin Marinas, James Morris, Serge E. Hallyn,
Arnd Bergmann, Masahiro Yamada, Krzysztof Kozlowski,
Marc Zyngier, Kees Cook, Andreas Färber, Ard Biesheuvel,
Ingo Molnar, Andrew Morton, Mike Rapoport, Mark Rutland,
David Brazdil, James Morse, Linux ARM, linux-kernel,
linux-security-module
On Wed, Mar 10, 2021 at 5:43 AM Jian Cai <jiancai@google.com> wrote:
> On Sat, Mar 6, 2021 at 4:25 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> > On Fri, Mar 5, 2021 at 12:23 AM Jian Cai <jiancai@google.com> wrote:
> > > On Wed, Mar 3, 2021 at 7:04 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> > > I think gcc also has these options.
> > > https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html
> >
> > And how does that work with this part of your patch:
> >
> > +#define SLS_TEXT \
> > + ALIGN_FUNCTION(); \
> > + *(.text.__llvm_slsblr_thunk_*)
> >
> > This does not look compiler agnostic?
>
> You are right, GCC does generate different oraphan section names. I
> will address it in the next version of the patch. Also it seems only
> arm64 gcc supports -mharden-sls=* at this moment, arm32 gcc does not
> support it yet. I don't know if there is any plan to implement it for
> 32-bit gcc, but should we patch arm32 linker script preemptively,
> assuming the sections will be named with the same pattern like how
> clang does so the kernel would not fail to boot when the flag is
> implemented?
I think the best thing is to have something like this:
Implement a macro such as this in
include/linux/compiler-clang.h
#define SLS_TEXT_SECTION *(.text.__llvm_slsblr_thunk_*)
then the corresponding in include/linux/compiler-gcc.h
but here also add a
#define SLS_TEXT_SECTION #error "no compiler support"
if the compiler version does not have this.
I don't know the exact best approach sadly, as the patch
looks now it seems a bit fragile, I wonder if you get linker
warnings when this section is unused?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v5] ARM: Implement SLS mitigation
@ 2021-03-22 11:45 ` Linus Walleij
0 siblings, 0 replies; 58+ messages in thread
From: Linus Walleij @ 2021-03-22 11:45 UTC (permalink / raw)
To: Jian Cai
Cc: Nick Desaulniers, Manoj Gupta, Luis Lozano, clang-built-linux,
Nathan Chancellor, David Laight, Will Deacon, Russell King,
Russell King, Catalin Marinas, James Morris, Serge E. Hallyn,
Arnd Bergmann, Masahiro Yamada, Krzysztof Kozlowski,
Marc Zyngier, Kees Cook, Andreas Färber, Ard Biesheuvel,
Ingo Molnar, Andrew Morton, Mike Rapoport, Mark Rutland,
David Brazdil, James Morse, Linux ARM, linux-kernel,
linux-security-module
On Wed, Mar 10, 2021 at 5:43 AM Jian Cai <jiancai@google.com> wrote:
> On Sat, Mar 6, 2021 at 4:25 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> > On Fri, Mar 5, 2021 at 12:23 AM Jian Cai <jiancai@google.com> wrote:
> > > On Wed, Mar 3, 2021 at 7:04 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> > > I think gcc also has these options.
> > > https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html
> >
> > And how does that work with this part of your patch:
> >
> > +#define SLS_TEXT \
> > + ALIGN_FUNCTION(); \
> > + *(.text.__llvm_slsblr_thunk_*)
> >
> > This does not look compiler agnostic?
>
> You are right, GCC does generate different oraphan section names. I
> will address it in the next version of the patch. Also it seems only
> arm64 gcc supports -mharden-sls=* at this moment, arm32 gcc does not
> support it yet. I don't know if there is any plan to implement it for
> 32-bit gcc, but should we patch arm32 linker script preemptively,
> assuming the sections will be named with the same pattern like how
> clang does so the kernel would not fail to boot when the flag is
> implemented?
I think the best thing is to have something like this:
Implement a macro such as this in
include/linux/compiler-clang.h
#define SLS_TEXT_SECTION *(.text.__llvm_slsblr_thunk_*)
then the corresponding in include/linux/compiler-gcc.h
but here also add a
#define SLS_TEXT_SECTION #error "no compiler support"
if the compiler version does not have this.
I don't know the exact best approach sadly, as the patch
looks now it seems a bit fragile, I wonder if you get linker
warnings when this section is unused?
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v5] ARM: Implement SLS mitigation
2021-03-22 11:45 ` Linus Walleij
@ 2021-03-23 22:39 ` Jian Cai
-1 siblings, 0 replies; 58+ messages in thread
From: Jian Cai @ 2021-03-23 22:39 UTC (permalink / raw)
To: Linus Walleij
Cc: Nick Desaulniers, Manoj Gupta, Luis Lozano, clang-built-linux,
Nathan Chancellor, David Laight, Will Deacon, Russell King,
Russell King, Catalin Marinas, James Morris, Serge E. Hallyn,
Arnd Bergmann, Masahiro Yamada, Krzysztof Kozlowski,
Marc Zyngier, Kees Cook, Andreas Färber, Ard Biesheuvel,
Ingo Molnar, Andrew Morton, Mike Rapoport, Mark Rutland,
David Brazdil, James Morse, Linux ARM, linux-kernel,
linux-security-module
Thanks for the suggestion. I've sent an inquiry to the author of
-mharden-sls* in GCC and hopefully that would shed some more light. We
do get warnings for oraphon sections when using lld. The other linkers
do not seem to provide such warnings, although the boot failure also
does not seem to happen with them.
On Mon, Mar 22, 2021 at 4:45 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Wed, Mar 10, 2021 at 5:43 AM Jian Cai <jiancai@google.com> wrote:
> > On Sat, Mar 6, 2021 at 4:25 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> > > On Fri, Mar 5, 2021 at 12:23 AM Jian Cai <jiancai@google.com> wrote:
> > > > On Wed, Mar 3, 2021 at 7:04 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> > > > I think gcc also has these options.
> > > > https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html
> > >
> > > And how does that work with this part of your patch:
> > >
> > > +#define SLS_TEXT \
> > > + ALIGN_FUNCTION(); \
> > > + *(.text.__llvm_slsblr_thunk_*)
> > >
> > > This does not look compiler agnostic?
> >
> > You are right, GCC does generate different oraphan section names. I
> > will address it in the next version of the patch. Also it seems only
> > arm64 gcc supports -mharden-sls=* at this moment, arm32 gcc does not
> > support it yet. I don't know if there is any plan to implement it for
> > 32-bit gcc, but should we patch arm32 linker script preemptively,
> > assuming the sections will be named with the same pattern like how
> > clang does so the kernel would not fail to boot when the flag is
> > implemented?
>
> I think the best thing is to have something like this:
> Implement a macro such as this in
> include/linux/compiler-clang.h
>
> #define SLS_TEXT_SECTION *(.text.__llvm_slsblr_thunk_*)
>
> then the corresponding in include/linux/compiler-gcc.h
> but here also add a
>
> #define SLS_TEXT_SECTION #error "no compiler support"
>
> if the compiler version does not have this.
>
> I don't know the exact best approach sadly, as the patch
> looks now it seems a bit fragile, I wonder if you get linker
> warnings when this section is unused?
>
> Yours,
> Linus Walleij
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v5] ARM: Implement SLS mitigation
@ 2021-03-23 22:39 ` Jian Cai
0 siblings, 0 replies; 58+ messages in thread
From: Jian Cai @ 2021-03-23 22:39 UTC (permalink / raw)
To: Linus Walleij
Cc: Nick Desaulniers, Manoj Gupta, Luis Lozano, clang-built-linux,
Nathan Chancellor, David Laight, Will Deacon, Russell King,
Russell King, Catalin Marinas, James Morris, Serge E. Hallyn,
Arnd Bergmann, Masahiro Yamada, Krzysztof Kozlowski,
Marc Zyngier, Kees Cook, Andreas Färber, Ard Biesheuvel,
Ingo Molnar, Andrew Morton, Mike Rapoport, Mark Rutland,
David Brazdil, James Morse, Linux ARM, linux-kernel,
linux-security-module
Thanks for the suggestion. I've sent an inquiry to the author of
-mharden-sls* in GCC and hopefully that would shed some more light. We
do get warnings for oraphon sections when using lld. The other linkers
do not seem to provide such warnings, although the boot failure also
does not seem to happen with them.
On Mon, Mar 22, 2021 at 4:45 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Wed, Mar 10, 2021 at 5:43 AM Jian Cai <jiancai@google.com> wrote:
> > On Sat, Mar 6, 2021 at 4:25 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> > > On Fri, Mar 5, 2021 at 12:23 AM Jian Cai <jiancai@google.com> wrote:
> > > > On Wed, Mar 3, 2021 at 7:04 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> > > > I think gcc also has these options.
> > > > https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html
> > >
> > > And how does that work with this part of your patch:
> > >
> > > +#define SLS_TEXT \
> > > + ALIGN_FUNCTION(); \
> > > + *(.text.__llvm_slsblr_thunk_*)
> > >
> > > This does not look compiler agnostic?
> >
> > You are right, GCC does generate different oraphan section names. I
> > will address it in the next version of the patch. Also it seems only
> > arm64 gcc supports -mharden-sls=* at this moment, arm32 gcc does not
> > support it yet. I don't know if there is any plan to implement it for
> > 32-bit gcc, but should we patch arm32 linker script preemptively,
> > assuming the sections will be named with the same pattern like how
> > clang does so the kernel would not fail to boot when the flag is
> > implemented?
>
> I think the best thing is to have something like this:
> Implement a macro such as this in
> include/linux/compiler-clang.h
>
> #define SLS_TEXT_SECTION *(.text.__llvm_slsblr_thunk_*)
>
> then the corresponding in include/linux/compiler-gcc.h
> but here also add a
>
> #define SLS_TEXT_SECTION #error "no compiler support"
>
> if the compiler version does not have this.
>
> I don't know the exact best approach sadly, as the patch
> looks now it seems a bit fragile, I wonder if you get linker
> warnings when this section is unused?
>
> Yours,
> Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v6] ARM: Implement SLS mitigation
2021-02-23 2:35 ` Jian Cai
@ 2021-03-05 0:53 ` Jian Cai
-1 siblings, 0 replies; 58+ messages in thread
From: Jian Cai @ 2021-03-05 0:53 UTC (permalink / raw)
Cc: ndesaulniers, manojgupta, llozano, clang-built-linux, Jian Cai,
Nathan Chancellor, David Laight, Will Deacon, Russell King,
Linus Walleij, Russell King, Catalin Marinas, James Morris,
Serge E. Hallyn, Arnd Bergmann, Masahiro Yamada, Kees Cook,
Andreas Färber, Daniel Palmer, Ard Biesheuvel, Ingo Molnar,
Vladimir Murzin, Marc Zyngier, Andrew Morton, Mike Rapoport,
Uwe Kleine-König, Mark Rutland, David Brazdil, Joey Gouly,
James Morse, linux-arm-kernel, linux-kernel,
linux-security-module
This patch adds CONFIG_HARDEN_SLS_ALL that can be used to turn on
-mharden-sls=all, which mitigates the straight-line speculation
vulnerability, speculative execution of the instruction following some
unconditional jumps. Notice -mharden-sls= has other options as below,
and this config turns on the strongest option.
all: enable all mitigations against Straight Line Speculation that are implemented.
none: disable all mitigations against Straight Line Speculation.
retbr: enable the mitigation against Straight Line Speculation for RET and BR instructions.
blr: enable the mitigation against Straight Line Speculation for BLR instructions.
Links:
https://reviews.llvm.org/D93221
https://reviews.llvm.org/D81404
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/frequently-asked-questions#SLS2
Suggested-by: Manoj Gupta <manojgupta@google.com>
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Suggested-by: Nathan Chancellor <nathan@kernel.org>
Suggested-by: David Laight <David.Laight@aculab.com>
Suggested-by: Will Deacon <will@kernel.org>
Suggested-by: Russell King <rmk+kernel@armlinux.org.uk>
Suggested-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jian Cai <jiancai@google.com>
---
Changes v1 -> v2:
Update the description and patch based on Nathan and David's comments.
Changes v2 -> v3:
Modify linker scripts as Nick suggested to address boot failure
(verified with qemu). Added more details in Kconfig.hardening
description. Disable the config by default.
Changes v3 -> v4:
Address Nathan's comment and replace def_bool with depends on in
HARDEN_SLS_ALL.
Changes v4 -> v5:
Removed "default n" and made the description target indepdent in
Kconfig.hardening.
Changes v5 -> v6:
Add select HARDEN_SLS_ALL under config HARDEN_BRANCH_PREDICTOR. This
turns on HARDEN_SLS_ALL by default where applicable.
arch/arm/Makefile | 4 ++++
arch/arm/include/asm/vmlinux.lds.h | 4 ++++
arch/arm/kernel/vmlinux.lds.S | 1 +
arch/arm/mm/Kconfig | 1 +
arch/arm64/Makefile | 4 ++++
arch/arm64/kernel/vmlinux.lds.S | 5 +++++
security/Kconfig.hardening | 8 ++++++++
7 files changed, 27 insertions(+)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index dad5502ecc28..54f9b5ff9682 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -48,6 +48,10 @@ CHECKFLAGS += -D__ARMEL__
KBUILD_LDFLAGS += -EL
endif
+ifeq ($(CONFIG_HARDEN_SLS_ALL), y)
+KBUILD_CFLAGS += -mharden-sls=all
+endif
+
#
# The Scalar Replacement of Aggregates (SRA) optimization pass in GCC 4.9 and
# later may result in code being generated that handles signed short and signed
diff --git a/arch/arm/include/asm/vmlinux.lds.h b/arch/arm/include/asm/vmlinux.lds.h
index 4a91428c324d..c7f9717511ca 100644
--- a/arch/arm/include/asm/vmlinux.lds.h
+++ b/arch/arm/include/asm/vmlinux.lds.h
@@ -145,3 +145,7 @@
__edtcm_data = .; \
} \
. = __dtcm_start + SIZEOF(.data_dtcm);
+
+#define SLS_TEXT \
+ ALIGN_FUNCTION(); \
+ *(.text.__llvm_slsblr_thunk_*)
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index f7f4620d59c3..e71f2bc97bae 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -63,6 +63,7 @@ SECTIONS
.text : { /* Real text segment */
_stext = .; /* Text and read-only data */
ARM_TEXT
+ SLS_TEXT
}
#ifdef CONFIG_DEBUG_ALIGN_RODATA
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 35f43d0aa056..bdb63e7b1bec 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -837,6 +837,7 @@ config HARDEN_BRANCH_PREDICTOR
bool "Harden the branch predictor against aliasing attacks" if EXPERT
depends on CPU_SPECTRE
default y
+ select HARDEN_SLS_ALL
help
Speculation attacks against some high-performance processors rely
on being able to manipulate the branch predictor for a victim
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 5b84aec31ed3..e233bfbdb1c2 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -34,6 +34,10 @@ $(warning LSE atomics not supported by binutils)
endif
endif
+ifeq ($(CONFIG_HARDEN_SLS_ALL), y)
+KBUILD_CFLAGS += -mharden-sls=all
+endif
+
cc_has_k_constraint := $(call try-run,echo \
'int main(void) { \
asm volatile("and w0, w0, %w0" :: "K" (4294967295)); \
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 7eea7888bb02..d5c892605862 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -103,6 +103,10 @@ jiffies = jiffies_64;
#define TRAMP_TEXT
#endif
+#define SLS_TEXT \
+ ALIGN_FUNCTION(); \
+ *(.text.__llvm_slsblr_thunk_*)
+
/*
* The size of the PE/COFF section that covers the kernel image, which
* runs from _stext to _edata, must be a round multiple of the PE/COFF
@@ -154,6 +158,7 @@ SECTIONS
HIBERNATE_TEXT
TRAMP_TEXT
*(.fixup)
+ SLS_TEXT
*(.gnu.warning)
. = ALIGN(16);
*(.got) /* Global offset table */
diff --git a/security/Kconfig.hardening b/security/Kconfig.hardening
index 269967c4fc1b..db76ad732c14 100644
--- a/security/Kconfig.hardening
+++ b/security/Kconfig.hardening
@@ -121,6 +121,14 @@ choice
endchoice
+config HARDEN_SLS_ALL
+ bool "enable SLS vulnerability hardening"
+ depends on $(cc-option,-mharden-sls=all)
+ help
+ Enables straight-line speculation vulnerability hardening. This inserts
+ speculation barrier instruction sequences after certain unconditional jumps
+ to prevent speculative execution past those barriers.
+
config GCC_PLUGIN_STRUCTLEAK_VERBOSE
bool "Report forcefully initialized variables"
depends on GCC_PLUGIN_STRUCTLEAK
--
2.30.1.766.gb4fecdf3b7-goog
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v6] ARM: Implement SLS mitigation
@ 2021-03-05 0:53 ` Jian Cai
0 siblings, 0 replies; 58+ messages in thread
From: Jian Cai @ 2021-03-05 0:53 UTC (permalink / raw)
Cc: ndesaulniers, manojgupta, llozano, clang-built-linux, Jian Cai,
Nathan Chancellor, David Laight, Will Deacon, Russell King,
Linus Walleij, Russell King, Catalin Marinas, James Morris,
Serge E. Hallyn, Arnd Bergmann, Masahiro Yamada, Kees Cook,
Andreas Färber, Daniel Palmer, Ard Biesheuvel, Ingo Molnar,
Vladimir Murzin, Marc Zyngier, Andrew Morton, Mike Rapoport,
Uwe Kleine-König, Mark Rutland, David Brazdil, Joey Gouly,
James Morse, linux-arm-kernel, linux-kernel,
linux-security-module
This patch adds CONFIG_HARDEN_SLS_ALL that can be used to turn on
-mharden-sls=all, which mitigates the straight-line speculation
vulnerability, speculative execution of the instruction following some
unconditional jumps. Notice -mharden-sls= has other options as below,
and this config turns on the strongest option.
all: enable all mitigations against Straight Line Speculation that are implemented.
none: disable all mitigations against Straight Line Speculation.
retbr: enable the mitigation against Straight Line Speculation for RET and BR instructions.
blr: enable the mitigation against Straight Line Speculation for BLR instructions.
Links:
https://reviews.llvm.org/D93221
https://reviews.llvm.org/D81404
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/frequently-asked-questions#SLS2
Suggested-by: Manoj Gupta <manojgupta@google.com>
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Suggested-by: Nathan Chancellor <nathan@kernel.org>
Suggested-by: David Laight <David.Laight@aculab.com>
Suggested-by: Will Deacon <will@kernel.org>
Suggested-by: Russell King <rmk+kernel@armlinux.org.uk>
Suggested-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jian Cai <jiancai@google.com>
---
Changes v1 -> v2:
Update the description and patch based on Nathan and David's comments.
Changes v2 -> v3:
Modify linker scripts as Nick suggested to address boot failure
(verified with qemu). Added more details in Kconfig.hardening
description. Disable the config by default.
Changes v3 -> v4:
Address Nathan's comment and replace def_bool with depends on in
HARDEN_SLS_ALL.
Changes v4 -> v5:
Removed "default n" and made the description target indepdent in
Kconfig.hardening.
Changes v5 -> v6:
Add select HARDEN_SLS_ALL under config HARDEN_BRANCH_PREDICTOR. This
turns on HARDEN_SLS_ALL by default where applicable.
arch/arm/Makefile | 4 ++++
arch/arm/include/asm/vmlinux.lds.h | 4 ++++
arch/arm/kernel/vmlinux.lds.S | 1 +
arch/arm/mm/Kconfig | 1 +
arch/arm64/Makefile | 4 ++++
arch/arm64/kernel/vmlinux.lds.S | 5 +++++
security/Kconfig.hardening | 8 ++++++++
7 files changed, 27 insertions(+)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index dad5502ecc28..54f9b5ff9682 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -48,6 +48,10 @@ CHECKFLAGS += -D__ARMEL__
KBUILD_LDFLAGS += -EL
endif
+ifeq ($(CONFIG_HARDEN_SLS_ALL), y)
+KBUILD_CFLAGS += -mharden-sls=all
+endif
+
#
# The Scalar Replacement of Aggregates (SRA) optimization pass in GCC 4.9 and
# later may result in code being generated that handles signed short and signed
diff --git a/arch/arm/include/asm/vmlinux.lds.h b/arch/arm/include/asm/vmlinux.lds.h
index 4a91428c324d..c7f9717511ca 100644
--- a/arch/arm/include/asm/vmlinux.lds.h
+++ b/arch/arm/include/asm/vmlinux.lds.h
@@ -145,3 +145,7 @@
__edtcm_data = .; \
} \
. = __dtcm_start + SIZEOF(.data_dtcm);
+
+#define SLS_TEXT \
+ ALIGN_FUNCTION(); \
+ *(.text.__llvm_slsblr_thunk_*)
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index f7f4620d59c3..e71f2bc97bae 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -63,6 +63,7 @@ SECTIONS
.text : { /* Real text segment */
_stext = .; /* Text and read-only data */
ARM_TEXT
+ SLS_TEXT
}
#ifdef CONFIG_DEBUG_ALIGN_RODATA
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 35f43d0aa056..bdb63e7b1bec 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -837,6 +837,7 @@ config HARDEN_BRANCH_PREDICTOR
bool "Harden the branch predictor against aliasing attacks" if EXPERT
depends on CPU_SPECTRE
default y
+ select HARDEN_SLS_ALL
help
Speculation attacks against some high-performance processors rely
on being able to manipulate the branch predictor for a victim
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 5b84aec31ed3..e233bfbdb1c2 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -34,6 +34,10 @@ $(warning LSE atomics not supported by binutils)
endif
endif
+ifeq ($(CONFIG_HARDEN_SLS_ALL), y)
+KBUILD_CFLAGS += -mharden-sls=all
+endif
+
cc_has_k_constraint := $(call try-run,echo \
'int main(void) { \
asm volatile("and w0, w0, %w0" :: "K" (4294967295)); \
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 7eea7888bb02..d5c892605862 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -103,6 +103,10 @@ jiffies = jiffies_64;
#define TRAMP_TEXT
#endif
+#define SLS_TEXT \
+ ALIGN_FUNCTION(); \
+ *(.text.__llvm_slsblr_thunk_*)
+
/*
* The size of the PE/COFF section that covers the kernel image, which
* runs from _stext to _edata, must be a round multiple of the PE/COFF
@@ -154,6 +158,7 @@ SECTIONS
HIBERNATE_TEXT
TRAMP_TEXT
*(.fixup)
+ SLS_TEXT
*(.gnu.warning)
. = ALIGN(16);
*(.got) /* Global offset table */
diff --git a/security/Kconfig.hardening b/security/Kconfig.hardening
index 269967c4fc1b..db76ad732c14 100644
--- a/security/Kconfig.hardening
+++ b/security/Kconfig.hardening
@@ -121,6 +121,14 @@ choice
endchoice
+config HARDEN_SLS_ALL
+ bool "enable SLS vulnerability hardening"
+ depends on $(cc-option,-mharden-sls=all)
+ help
+ Enables straight-line speculation vulnerability hardening. This inserts
+ speculation barrier instruction sequences after certain unconditional jumps
+ to prevent speculative execution past those barriers.
+
config GCC_PLUGIN_STRUCTLEAK_VERBOSE
bool "Report forcefully initialized variables"
depends on GCC_PLUGIN_STRUCTLEAK
--
2.30.1.766.gb4fecdf3b7-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 58+ messages in thread
* Re: [PATCH v6] ARM: Implement SLS mitigation
2021-03-05 0:53 ` Jian Cai
@ 2021-03-05 9:52 ` Will Deacon
-1 siblings, 0 replies; 58+ messages in thread
From: Will Deacon @ 2021-03-05 9:52 UTC (permalink / raw)
To: Jian Cai
Cc: ndesaulniers, manojgupta, llozano, clang-built-linux,
Nathan Chancellor, David Laight, Russell King, Linus Walleij,
Russell King, Catalin Marinas, James Morris, Serge E. Hallyn,
Arnd Bergmann, Masahiro Yamada, Kees Cook, Andreas Färber,
Daniel Palmer, Ard Biesheuvel, Ingo Molnar, Vladimir Murzin,
Marc Zyngier, Andrew Morton, Mike Rapoport,
Uwe Kleine-König, Mark Rutland, David Brazdil, Joey Gouly,
James Morse, linux-arm-kernel, linux-kernel,
linux-security-module
On Thu, Mar 04, 2021 at 04:53:18PM -0800, Jian Cai wrote:
> This patch adds CONFIG_HARDEN_SLS_ALL that can be used to turn on
> -mharden-sls=all, which mitigates the straight-line speculation
> vulnerability, speculative execution of the instruction following some
> unconditional jumps. Notice -mharden-sls= has other options as below,
> and this config turns on the strongest option.
>
> all: enable all mitigations against Straight Line Speculation that are implemented.
> none: disable all mitigations against Straight Line Speculation.
> retbr: enable the mitigation against Straight Line Speculation for RET and BR instructions.
> blr: enable the mitigation against Straight Line Speculation for BLR instructions.
>
> Links:
> https://reviews.llvm.org/D93221
> https://reviews.llvm.org/D81404
> https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation
> https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/frequently-asked-questions#SLS2
>
> Suggested-by: Manoj Gupta <manojgupta@google.com>
> Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
> Suggested-by: Nathan Chancellor <nathan@kernel.org>
> Suggested-by: David Laight <David.Laight@aculab.com>
> Suggested-by: Will Deacon <will@kernel.org>
I'm still reasonably opposed to this patch, so please don't add my
"Suggested-by" here as, if I were to suggest anything, it would be not
to apply this patch :)
I still don't see why SLS is worth a compiler mitigation which will affect
all CPUs that run the kernel binary, but Spectre-v1 is not. In other words,
the big thing missing from this is a justification as to why SLS is a
problem worth working around for general C code.
Will
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v6] ARM: Implement SLS mitigation
@ 2021-03-05 9:52 ` Will Deacon
0 siblings, 0 replies; 58+ messages in thread
From: Will Deacon @ 2021-03-05 9:52 UTC (permalink / raw)
To: Jian Cai
Cc: ndesaulniers, manojgupta, llozano, clang-built-linux,
Nathan Chancellor, David Laight, Russell King, Linus Walleij,
Russell King, Catalin Marinas, James Morris, Serge E. Hallyn,
Arnd Bergmann, Masahiro Yamada, Kees Cook, Andreas Färber,
Daniel Palmer, Ard Biesheuvel, Ingo Molnar, Vladimir Murzin,
Marc Zyngier, Andrew Morton, Mike Rapoport,
Uwe Kleine-König, Mark Rutland, David Brazdil, Joey Gouly,
James Morse, linux-arm-kernel, linux-kernel,
linux-security-module
On Thu, Mar 04, 2021 at 04:53:18PM -0800, Jian Cai wrote:
> This patch adds CONFIG_HARDEN_SLS_ALL that can be used to turn on
> -mharden-sls=all, which mitigates the straight-line speculation
> vulnerability, speculative execution of the instruction following some
> unconditional jumps. Notice -mharden-sls= has other options as below,
> and this config turns on the strongest option.
>
> all: enable all mitigations against Straight Line Speculation that are implemented.
> none: disable all mitigations against Straight Line Speculation.
> retbr: enable the mitigation against Straight Line Speculation for RET and BR instructions.
> blr: enable the mitigation against Straight Line Speculation for BLR instructions.
>
> Links:
> https://reviews.llvm.org/D93221
> https://reviews.llvm.org/D81404
> https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation
> https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/frequently-asked-questions#SLS2
>
> Suggested-by: Manoj Gupta <manojgupta@google.com>
> Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
> Suggested-by: Nathan Chancellor <nathan@kernel.org>
> Suggested-by: David Laight <David.Laight@aculab.com>
> Suggested-by: Will Deacon <will@kernel.org>
I'm still reasonably opposed to this patch, so please don't add my
"Suggested-by" here as, if I were to suggest anything, it would be not
to apply this patch :)
I still don't see why SLS is worth a compiler mitigation which will affect
all CPUs that run the kernel binary, but Spectre-v1 is not. In other words,
the big thing missing from this is a justification as to why SLS is a
problem worth working around for general C code.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v6] ARM: Implement SLS mitigation
2021-03-05 9:52 ` Will Deacon
@ 2021-03-06 12:27 ` Linus Walleij
-1 siblings, 0 replies; 58+ messages in thread
From: Linus Walleij @ 2021-03-06 12:27 UTC (permalink / raw)
To: Will Deacon
Cc: Jian Cai, Nick Desaulniers, Manoj Gupta, Luis Lozano,
clang-built-linux, Nathan Chancellor, David Laight, Russell King,
Russell King, Catalin Marinas, James Morris, Serge E. Hallyn,
Arnd Bergmann, Masahiro Yamada, Kees Cook, Andreas Färber,
Daniel Palmer, Ard Biesheuvel, Ingo Molnar, Vladimir Murzin,
Marc Zyngier, Andrew Morton, Mike Rapoport,
Uwe Kleine-König, Mark Rutland, David Brazdil, Joey Gouly,
James Morse, Linux ARM, linux-kernel, linux-security-module
On Fri, Mar 5, 2021 at 10:53 AM Will Deacon <will@kernel.org> wrote:
> I still don't see why SLS is worth a compiler mitigation which will affect
> all CPUs that run the kernel binary, but Spectre-v1 is not. In other words,
> the big thing missing from this is a justification as to why SLS is a
> problem worth working around for general C code.
I might be on the Dunning Kruger-scale of a little knowledge is dangerous
here, but AFAICT it is because it is mitigating all branches that result
from the compilation.
I think the people who devised this approach didn't think about the
kernel problem per se but about "any code".
They would have to go back to the compilers, have them introduce
a marker instead for each branch or return, and then emit symbols
that the kernel can run-time patch to mitigate the vulnerability.
Something like that. (I guess.)
Notice that these symbols/pointers would first have a
footprint impact, though maybe they could be discarded if
not applicable.
The patch says:
It inserts speculation barrier sequences (SB or DSB+ISB
depending on the target architecture) after RET and BR, and
replacing BLR with BL+BR sequence.
How would you do that at runtime? If you slot in NOPs
around the branch for mitigating, there will still be impact.
If you want to make the code look the same unless vulnerable,
you would have to patch the branch with a branch to another
place to do the barriers... that patched branch in turn could
be speculated? I feel stupid here. But I guess someone could
come up with something?
So instead of a simple straight-forward solution that becomes a
really complicated awkward solution that generate a few thousand
more man-hours and delays the mitigations. So I understand if
the authors would want to try the simple approach
first.
It may however be our job to say "no, go do the really
complicated thing", I guess that is what you're saying. :)
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v6] ARM: Implement SLS mitigation
@ 2021-03-06 12:27 ` Linus Walleij
0 siblings, 0 replies; 58+ messages in thread
From: Linus Walleij @ 2021-03-06 12:27 UTC (permalink / raw)
To: Will Deacon
Cc: Jian Cai, Nick Desaulniers, Manoj Gupta, Luis Lozano,
clang-built-linux, Nathan Chancellor, David Laight, Russell King,
Russell King, Catalin Marinas, James Morris, Serge E. Hallyn,
Arnd Bergmann, Masahiro Yamada, Kees Cook, Andreas Färber,
Daniel Palmer, Ard Biesheuvel, Ingo Molnar, Vladimir Murzin,
Marc Zyngier, Andrew Morton, Mike Rapoport,
Uwe Kleine-König, Mark Rutland, David Brazdil, Joey Gouly,
James Morse, Linux ARM, linux-kernel, linux-security-module
On Fri, Mar 5, 2021 at 10:53 AM Will Deacon <will@kernel.org> wrote:
> I still don't see why SLS is worth a compiler mitigation which will affect
> all CPUs that run the kernel binary, but Spectre-v1 is not. In other words,
> the big thing missing from this is a justification as to why SLS is a
> problem worth working around for general C code.
I might be on the Dunning Kruger-scale of a little knowledge is dangerous
here, but AFAICT it is because it is mitigating all branches that result
from the compilation.
I think the people who devised this approach didn't think about the
kernel problem per se but about "any code".
They would have to go back to the compilers, have them introduce
a marker instead for each branch or return, and then emit symbols
that the kernel can run-time patch to mitigate the vulnerability.
Something like that. (I guess.)
Notice that these symbols/pointers would first have a
footprint impact, though maybe they could be discarded if
not applicable.
The patch says:
It inserts speculation barrier sequences (SB or DSB+ISB
depending on the target architecture) after RET and BR, and
replacing BLR with BL+BR sequence.
How would you do that at runtime? If you slot in NOPs
around the branch for mitigating, there will still be impact.
If you want to make the code look the same unless vulnerable,
you would have to patch the branch with a branch to another
place to do the barriers... that patched branch in turn could
be speculated? I feel stupid here. But I guess someone could
come up with something?
So instead of a simple straight-forward solution that becomes a
really complicated awkward solution that generate a few thousand
more man-hours and delays the mitigations. So I understand if
the authors would want to try the simple approach
first.
It may however be our job to say "no, go do the really
complicated thing", I guess that is what you're saying. :)
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 58+ messages in thread