linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nick Desaulniers <ndesaulniers@google.com>
To: Jian Cai <jiancai@google.com>
Cc: "Manoj Gupta" <manojgupta@google.com>,
	"Luis Lozano" <llozano@google.com>,
	clang-built-linux <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>,
	"Will Deacon" <will@kernel.org>,
	"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" <linux-arm-kernel@lists.infradead.org>,
	LKML <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 10:20:06 -0800	[thread overview]
Message-ID: <CAKwvOdn7N9dRfjrR0NiE6Dc_f_6PU-_4g1G5uRcoAvnob51ZfA@mail.gmail.com> (raw)
In-Reply-To: <20210212195255.1321544-1-jiancai@google.com>

On Fri, Feb 12, 2021 at 11:53 AM 'Jian Cai' via Clang Built Linux
<clang-built-linux@googlegroups.com> wrote:

The oneline of the commit is "ARM: Implement Clang's SLS mitigation,"
but that's not precise. GCC implements the same flag with the same
arguments.  There is nothing compiler specific about this patch.
(Though perhaps different section names are used, see below).

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

I observe lots of linker warnings with this applied on linux-next:
ld.lld: warning:
init/built-in.a(main.o):(.text.__llvm_slsblr_thunk_x0) is being placed
in '.text.__llvm_slsblr_thunk_x0'
You need to modify arch/arm64/kernel/vmlinux.lds.S and
arch/arm/kernel/vmlinux.lds.S (and possibly
arch/arm/boot/compressed/vmlinux.lds.S as well) to add these sections
back into .text so that the linkers don't place these orphaned
sections in wild places.  The resulting aarch64 kernel image doesn't
even boot (under emulation).

For 32b ARM:
ld.lld: warning:
init/built-in.a(main.o):(.text.__llvm_slsblr_thunk_arm_r0) is being
placed in '.text.__llvm_slsblr_thunk_arm_r0'
...
ld.lld: warning:
init/built-in.a(main.o):(.text.__llvm_slsblr_thunk_thumb_r0) is being
placed in '.text.__llvm_slsblr_thunk_thumb_r0'
...
<trimmed, but there's close to 60 of these>

And the image doesn't boot (under emulation).

> ---
>
> 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
> +
>  cc_has_k_constraint := $(call try-run,echo                             \
>         'int main(void) {                                               \
>                 asm volatile("and w0, w0, %w0" :: "K" (4294967295));    \
> diff --git a/security/Kconfig.hardening b/security/Kconfig.hardening
> index 269967c4fc1b..9266d8d1f78f 100644
> --- a/security/Kconfig.hardening
> +++ b/security/Kconfig.hardening
> @@ -121,6 +121,13 @@ choice
>
>  endchoice
>
> +config HARDEN_SLS_ALL
> +       bool "enable SLS vulnerability hardening"
> +       def_bool $(cc-option,-mharden-sls=all)

This fails to set CONFIG_HARDEN_SLS_ALL for me with:
$ ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make LLVM=1 LLVM_IAS=1
-j72 defconfig
$ grep SLS_ALL .config
# CONFIG_HARDEN_SLS_ALL is not set

but it's flipped on there for arm64 defconfig:
$ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make LLVM=1 LLVM_IAS=1
-j72 defconfig
$ grep SLS_ALL .config
CONFIG_HARDEN_SLS_ALL=y

What's going on there?  Is the cc-option Kconfig macro broken for
Clang when cross compiling 32b ARM?  I can still enable
CONFIG_HARDEN_SLS_ALL via menuconfig, but I wonder if the default
value is funny because the cc-option check is failing?

> +        help
> +          Enables straight-line speculation vulnerability hardening
> +         at highest level.
> +
>  config GCC_PLUGIN_STRUCTLEAK_VERBOSE
>         bool "Report forcefully initialized variables"
>         depends on GCC_PLUGIN_STRUCTLEAK
> --

-- 
Thanks,
~Nick Desaulniers

  parent reply	other threads:[~2021-02-17 18:21 UTC|newest]

Thread overview: 29+ 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:55 ` Nathan Chancellor
2021-02-12 10:41   ` David Laight
2021-02-12 19:52     ` [PATCH v2] " Jian Cai
2021-02-17  9:49       ` Will Deacon
2021-02-17 11:05         ` David Laight
2021-03-25 14:01         ` Linus Walleij
2021-02-17 18:20       ` Nick Desaulniers [this message]
2021-02-19 20:18       ` [PATCH v3] ARM: Implement " Jian Cai
2021-02-19 20:30         ` Nathan Chancellor
2021-02-19 23:08         ` [PATCH v4] " Jian Cai
2021-02-21 10:13           ` Russell King - ARM Linux admin
2021-02-22 11:58           ` Will Deacon
2021-02-22 21:50             ` Jian Cai
2021-02-23 10:04               ` Will Deacon
2021-03-03 15:18                 ` Linus Walleij
2021-03-03 15:29                   ` David Laight
2021-03-03 15:31                     ` Linus Walleij
2021-02-23  2:31           ` [PATCH v5] " Jian Cai
2021-02-23  2:35             ` Jian Cai
2021-03-03 15:04               ` Linus Walleij
2021-03-04 23:22                 ` Jian Cai
2021-03-06 12:25                   ` Linus Walleij
2021-03-10  4:43                     ` Jian Cai
2021-03-22 11:45                       ` Linus Walleij
2021-03-23 22:39                         ` Jian Cai
2021-03-05  0:53               ` [PATCH v6] " Jian Cai
2021-03-05  9:52                 ` Will Deacon
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=CAKwvOdn7N9dRfjrR0NiE6Dc_f_6PU-_4g1G5uRcoAvnob51ZfA@mail.gmail.com \
    --to=ndesaulniers@google.com \
    --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=serge@hallyn.com \
    --cc=will@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).