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" <rmk+kernel@armlinux.org.uk>,
	"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>,
	"Andreas Färber" <afaerber@suse.de>,
	"Daniel Palmer" <daniel@0x0f.com>,
	"Ard Biesheuvel" <ardb@kernel.org>,
	"Ingo Molnar" <mingo@kernel.org>,
	"Vladimir Murzin" <vladimir.murzin@arm.com>,
	"Marc Zyngier" <maz@kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Mike Rapoport" <rppt@kernel.org>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"David Brazdil" <dbrazdil@google.com>,
	"Joey Gouly" <joey.gouly@arm.com>,
	"James Morse" <james.morse@arm.com>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-security-module@vger.kernel.org
Subject: Re: [PATCH v6] ARM: Implement SLS mitigation
Date: Sat, 6 Mar 2021 13:27:54 +0100	[thread overview]
Message-ID: <CACRpkdYioQs4poAbUp1zCennOfFhGEY59q3Qht6s9NC0fOUNEg@mail.gmail.com> (raw)
In-Reply-To: <20210305095256.GA22536@willie-the-truck>

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

      reply	other threads:[~2021-03-06 12:29 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-12  5:14 [PATCH] ARM: Implement Clang's " 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
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 [this message]

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=CACRpkdYioQs4poAbUp1zCennOfFhGEY59q3Qht6s9NC0fOUNEg@mail.gmail.com \
    --to=linus.walleij@linaro.org \
    --cc=David.Laight@aculab.com \
    --cc=afaerber@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=clang-built-linux@googlegroups.com \
    --cc=daniel@0x0f.com \
    --cc=dbrazdil@google.com \
    --cc=james.morse@arm.com \
    --cc=jiancai@google.com \
    --cc=jmorris@namei.org \
    --cc=joey.gouly@arm.com \
    --cc=keescook@chromium.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=mark.rutland@arm.com \
    --cc=masahiroy@kernel.org \
    --cc=maz@kernel.org \
    --cc=mingo@kernel.org \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=rppt@kernel.org \
    --cc=serge@hallyn.com \
    --cc=u.kleine-koenig@pengutronix.de \
    --cc=vladimir.murzin@arm.com \
    --cc=will@kernel.org \
    --subject='Re: [PATCH v6] ARM: Implement 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