From: Will Deacon <will@kernel.org> To: Jian Cai <jiancai@google.com> Cc: "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>, "Ard Biesheuvel" <ardb@kernel.org>, "Andreas Färber" <afaerber@suse.de>, "Ingo Molnar" <mingo@kernel.org>, "Linus Walleij" <linus.walleij@linaro.org>, "Marc Zyngier" <maz@kernel.org>, "Andrew Morton" <akpm@linux-foundation.org>, "Mike Rapoport" <rppt@kernel.org>, "Mark Rutland" <mark.rutland@arm.com>, "David Brazdil" <dbrazdil@google.com>, "James Morse" <james.morse@arm.com>, "Linux ARM" <linux-arm-kernel@lists.infradead.org>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, linux-security-module@vger.kernel.org Subject: Re: [PATCH v4] ARM: Implement SLS mitigation Date: Tue, 23 Feb 2021 10:04:53 +0000 [thread overview] Message-ID: <20210223100453.GB10254@willie-the-truck> (raw) In-Reply-To: <CA+SOCLJVGJSn67VU24wPDdsOVeHhGe+KO5ekOCusano=bhn1Mg@mail.gmail.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will@kernel.org> To: Jian Cai <jiancai@google.com> Cc: "Mark Rutland" <mark.rutland@arm.com>, "Catalin Marinas" <catalin.marinas@arm.com>, "Linus Walleij" <linus.walleij@linaro.org>, "James Morris" <jmorris@namei.org>, "Manoj Gupta" <manojgupta@google.com>, "Ingo Molnar" <mingo@kernel.org>, "Marc Zyngier" <maz@kernel.org>, "Masahiro Yamada" <masahiroy@kernel.org>, "Russell King" <linux@armlinux.org.uk>, "Ard Biesheuvel" <ardb@kernel.org>, clang-built-linux <clang-built-linux@googlegroups.com>, "Luis Lozano" <llozano@google.com>, "David Brazdil" <dbrazdil@google.com>, "Serge E. Hallyn" <serge@hallyn.com>, "Kees Cook" <keescook@chromium.org>, "Arnd Bergmann" <arnd@arndb.de>, "Nathan Chancellor" <nathan@kernel.org>, "Linux ARM" <linux-arm-kernel@lists.infradead.org>, "Nick Desaulniers" <ndesaulniers@google.com>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, linux-security-module@vger.kernel.org, "David Laight" <David.Laight@aculab.com>, "James Morse" <james.morse@arm.com>, "Andrew Morton" <akpm@linux-foundation.org>, "Andreas Färber" <afaerber@suse.de>, "Mike Rapoport" <rppt@kernel.org> Subject: Re: [PATCH v4] ARM: Implement SLS mitigation Date: Tue, 23 Feb 2021 10:04:53 +0000 [thread overview] Message-ID: <20210223100453.GB10254@willie-the-truck> (raw) In-Reply-To: <CA+SOCLJVGJSn67VU24wPDdsOVeHhGe+KO5ekOCusano=bhn1Mg@mail.gmail.com> 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
next prev parent reply other threads:[~2021-02-23 10:06 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 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 [this message] 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=20210223100453.GB10254@willie-the-truck \ --to=will@kernel.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=dbrazdil@google.com \ --cc=james.morse@arm.com \ --cc=jiancai@google.com \ --cc=jmorris@namei.org \ --cc=keescook@chromium.org \ --cc=linus.walleij@linaro.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=rppt@kernel.org \ --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: linkBe 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.