All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will@kernel.org>
To: Jian Cai <jiancai@google.com>
Cc: ndesaulniers@google.com, manojgupta@google.com,
	llozano@google.com, clang-built-linux@googlegroups.com,
	"Nathan Chancellor" <nathan@kernel.org>,
	"David Laight" <David.Laight@aculab.com>,
	"Russell King" <linux@armlinux.org.uk>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"James Morris" <jmorris@namei.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Masahiro Yamada" <masahiroy@kernel.org>,
	"Kees Cook" <keescook@chromium.org>,
	"Krzysztof Kozlowski" <krzk@kernel.org>,
	"Ard Biesheuvel" <ardb@kernel.org>,
	"Andreas Färber" <afaerber@suse.de>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org
Subject: Re: [PATCH v2] ARM: Implement Clang's SLS mitigation
Date: Wed, 17 Feb 2021 09:49:00 +0000	[thread overview]
Message-ID: <20210217094859.GA3706@willie-the-truck> (raw)
In-Reply-To: <20210212195255.1321544-1-jiancai@google.com>

On Fri, Feb 12, 2021 at 11:52:53AM -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.

What exactly does this mitigation do? This should be documented somewhere,
maybe in the Kconfig text?

> Link: https://reviews.llvm.org/D93221
> Link: https://reviews.llvm.org/D81404
> Link: 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: Nathan Chancellor  <nathan@kernel.org>
> Suggested-by: David Laight <David.Laight@aculab.com>
> Signed-off-by: Jian Cai <jiancai@google.com>
> ---
> 
> Changes v1 -> v2:
>  Update the description and patch based on Nathan and David's comments. 
> 
>  arch/arm/Makefile          | 4 ++++
>  arch/arm64/Makefile        | 4 ++++
>  security/Kconfig.hardening | 7 +++++++
>  3 files changed, 15 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/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

The big problem I have with this is that it's a compile-time decision.
For the other spectre crap we have a combination of the "mitigations=off"
command-line and CPU detection to avoid the cost of the mitigation where
it is not deemed necessary.

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). 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?

Will

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will@kernel.org>
To: Jian Cai <jiancai@google.com>
Cc: linux-kernel@vger.kernel.org, "Kees Cook" <keescook@chromium.org>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Masahiro Yamada" <masahiroy@kernel.org>,
	ndesaulniers@google.com, "Russell King" <linux@armlinux.org.uk>,
	"Krzysztof Kozlowski" <krzk@kernel.org>,
	"James Morris" <jmorris@namei.org>,
	"Nathan Chancellor" <nathan@kernel.org>,
	clang-built-linux@googlegroups.com,
	linux-security-module@vger.kernel.org,
	"David Laight" <David.Laight@aculab.com>,
	manojgupta@google.com, "Andreas Färber" <afaerber@suse.de>,
	llozano@google.com, "Ard Biesheuvel" <ardb@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	"Serge E. Hallyn" <serge@hallyn.com>
Subject: Re: [PATCH v2] ARM: Implement Clang's SLS mitigation
Date: Wed, 17 Feb 2021 09:49:00 +0000	[thread overview]
Message-ID: <20210217094859.GA3706@willie-the-truck> (raw)
In-Reply-To: <20210212195255.1321544-1-jiancai@google.com>

On Fri, Feb 12, 2021 at 11:52:53AM -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.

What exactly does this mitigation do? This should be documented somewhere,
maybe in the Kconfig text?

> Link: https://reviews.llvm.org/D93221
> Link: https://reviews.llvm.org/D81404
> Link: 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: Nathan Chancellor  <nathan@kernel.org>
> Suggested-by: David Laight <David.Laight@aculab.com>
> Signed-off-by: Jian Cai <jiancai@google.com>
> ---
> 
> Changes v1 -> v2:
>  Update the description and patch based on Nathan and David's comments. 
> 
>  arch/arm/Makefile          | 4 ++++
>  arch/arm64/Makefile        | 4 ++++
>  security/Kconfig.hardening | 7 +++++++
>  3 files changed, 15 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/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

The big problem I have with this is that it's a compile-time decision.
For the other spectre crap we have a combination of the "mitigations=off"
command-line and CPU detection to avoid the cost of the mitigation where
it is not deemed necessary.

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). 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?

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-02-17  9:50 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-12  5:14 [PATCH] ARM: Implement Clang's SLS mitigation Jian Cai
2021-02-12  5:14 ` Jian Cai
2021-02-12  5:55 ` Nathan Chancellor
2021-02-12  5:55   ` Nathan Chancellor
2021-02-12 10:41   ` David Laight
2021-02-12 10:41     ` David Laight
2021-02-12 19:52     ` [PATCH v2] " Jian Cai
2021-02-12 19:52       ` Jian Cai
2021-02-17  9:49       ` Will Deacon [this message]
2021-02-17  9:49         ` Will Deacon
2021-02-17 11:05         ` David Laight
2021-02-17 11:05           ` David Laight
2021-03-25 14:01         ` Linus Walleij
2021-03-25 14:01           ` Linus Walleij
2021-02-17 18:20       ` Nick Desaulniers
2021-02-17 18:20         ` Nick Desaulniers
2021-02-19 20:18       ` [PATCH v3] ARM: Implement " Jian Cai
2021-02-19 20:18         ` Jian Cai
2021-02-19 20:30         ` Nathan Chancellor
2021-02-19 20:30           ` Nathan Chancellor
2021-02-19 23:08         ` [PATCH v4] " Jian Cai
2021-02-19 23:08           ` Jian Cai
2021-02-21 10:13           ` Russell King - ARM Linux admin
2021-02-21 10:13             ` Russell King - ARM Linux admin
2021-02-22 11:58           ` Will Deacon
2021-02-22 11:58             ` Will Deacon
2021-02-22 21:50             ` Jian Cai
2021-02-22 21:50               ` Jian Cai
2021-02-23 10:04               ` Will Deacon
2021-02-23 10:04                 ` Will Deacon
2021-03-03 15:18                 ` Linus Walleij
2021-03-03 15:18                   ` Linus Walleij
2021-03-03 15:29                   ` David Laight
2021-03-03 15:29                     ` David Laight
2021-03-03 15:31                     ` Linus Walleij
2021-03-03 15:31                       ` Linus Walleij
2021-02-23  2:31           ` [PATCH v5] " Jian Cai
2021-02-23  2:31             ` Jian Cai
2021-02-23  2:35             ` Jian Cai
2021-02-23  2:35               ` Jian Cai
2021-03-03 15:04               ` Linus Walleij
2021-03-03 15:04                 ` Linus Walleij
2021-03-04 23:22                 ` Jian Cai
2021-03-04 23:22                   ` Jian Cai
2021-03-06 12:25                   ` Linus Walleij
2021-03-06 12:25                     ` Linus Walleij
2021-03-10  4:43                     ` Jian Cai
2021-03-10  4:43                       ` Jian Cai
2021-03-22 11:45                       ` Linus Walleij
2021-03-22 11:45                         ` Linus Walleij
2021-03-23 22:39                         ` Jian Cai
2021-03-23 22:39                           ` Jian Cai
2021-03-05  0:53               ` [PATCH v6] " Jian Cai
2021-03-05  0:53                 ` Jian Cai
2021-03-05  9:52                 ` Will Deacon
2021-03-05  9:52                   ` Will Deacon
2021-03-06 12:27                   ` Linus Walleij
2021-03-06 12:27                     ` Linus Walleij

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210217094859.GA3706@willie-the-truck \
    --to=will@kernel.org \
    --cc=David.Laight@aculab.com \
    --cc=afaerber@suse.de \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=clang-built-linux@googlegroups.com \
    --cc=jiancai@google.com \
    --cc=jmorris@namei.org \
    --cc=keescook@chromium.org \
    --cc=krzk@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=llozano@google.com \
    --cc=manojgupta@google.com \
    --cc=masahiroy@kernel.org \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=serge@hallyn.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.