linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: Will Deacon <will@kernel.org>
Cc: "Jian Cai" <jiancai@google.com>,
	"Nick Desaulniers" <ndesaulniers@google.com>,
	"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>,
	"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>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-security-module@vger.kernel.org,
	"Kristof Beyls" <kristof.beyls@arm.com>
Subject: Re: [PATCH v2] ARM: Implement Clang's SLS mitigation
Date: Thu, 25 Mar 2021 15:01:15 +0100	[thread overview]
Message-ID: <CACRpkdYHXrMPtkG09x9tscBzp2O=Ps-8m_03J6DcBnYcQuvWGg@mail.gmail.com> (raw)
In-Reply-To: <20210217094859.GA3706@willie-the-truck>

Hi Will,

I went back and found this feedback which is kind of the heart of the
issues regarding SLS.

On Wed, Feb 17, 2021 at 10:51 AM Will Deacon <will@kernel.org> wrote:

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

For newcomers, the way this works today can be found in e.g.:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/kernel/proton-pack.c
mitigations=off turns off Spectre v2 and v4 mitigations.

AFAICT this is achived with misc parameterization to firmware
and hypervisors and no runtime-patching of any code
at all?

(On ARM32 it has no effect whatsoever, we just turn on all
spectre v2 mitigations by default. No runtime choice.)

The way I understand it is that for SLS the compiler must at least
put in some kind of placeholders, but that it *might* be possible to do
runtime mitigations on top of that.

We need feedback from the compiler people as to what is
possible here.

If it is *not* possible to mitigate at run-time, then I don't know
what is the right thing to do. Certainly not to turn it on by default
as is done today?

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

There is such a compiler mitigation for Spectre v1, under
the name "Speculative load hardening" the kernel
is not (yet) enabling it.

https://llvm.org/docs/SpeculativeLoadHardening.html
it comes with the intuitive command line switch
-mspeculative-load-hardening

Certainly a separate patch can add speculative load
hardening support on top of this, or before this patch,
if there is desire and/or feels like a more coherent
approach.

As the article says "The performance overhead of this style of
comprehensive mitigation is very high (...) most large applications
seeing a 30% overhead or less."

I suppose it can be enabled while compiling the kernel just
like this patch enables -mharden-sls=all

I don't know if your comment means that if we enable one
of them we should just as well enable both or none as
otherwise there is no real protection, as attackers can
just use the other similar attack vector?

> Finally, do we have to worry about our assembly code?

AFAICT yes, and you seem to have hardened
Aarch64's ERET:s which seemed especially vulnerable
in commit
679db70801da9fda91d26caf13bf5b5ccc74e8e8
"arm64: entry: Place an SB sequence following an ERET instruction"
Link for people without kernel source:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=679db70801da9fda91d26caf13bf5b5ccc74e8e8

So it seems the most vulnerable spot was already
fixed by you, thanks! But I bet there are some more
spots.

Yours,
Linus Walleij

  parent reply	other threads:[~2021-03-25 14:02 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-12  5:14 [PATCH] " 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 [this message]
2021-02-17 18:20       ` Nick Desaulniers
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='CACRpkdYHXrMPtkG09x9tscBzp2O=Ps-8m_03J6DcBnYcQuvWGg@mail.gmail.com' \
    --to=linus.walleij@linaro.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=kristof.beyls@arm.com \
    --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 \
    --cc=will@kernel.org \
    --subject='Re: [PATCH v2] ARM: Implement Clang'\''s SLS mitigation' \
    /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

This is a public inbox, see mirroring instructions
on how to clone and mirror all data and code used for this inbox