Messages in this thread | | | From | Jian Cai <> | Date | Thu, 4 Mar 2021 15:22:51 -0800 | Subject | Re: [PATCH v5] ARM: Implement SLS mitigation |
| |
On Wed, Mar 3, 2021 at 7:04 AM Linus Walleij <linus.walleij@linaro.org> wrote: > > On Tue, Feb 23, 2021 at 3:36 AM Jian Cai <jiancai@google.com> 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. > > I heard about compiler protection for this, so nice to see it happening! > > Would you happen to know if there is any plan to do the same for GCC? > I know you folks at Google like LLVM, but if you know let us know.
I think gcc also has these options. https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html
> > > +config HARDEN_SLS_ALL > > + bool "enable SLS vulnerability hardening" > > I would go in and also edit arch/arm/mm/Kconfig under: > config HARDEN_BRANCH_PREDICTOR add > select HARDEN_SLS_ALL > > Because if the user wants hardening for branch prediction > in general then the user certainly wants this as well, if > available. The help text for that option literally says: > > "This config option will take CPU-specific actions to harden > the branch predictor against aliasing attacks and may rely on > specific instruction sequences or control bits being set by > the system firmware." > > Notice this only turns on for CPUs with CPU_SPECTRE > defined which makes sense. Also it is default y which fulfils > Will's request that it be turned on by default where > applicable. Notably it will not be turned on for pre-v7 silicon > which would be unhelpful as they don't suffer from > these bugs.
Thanks for the suggestion. I will update the patch.
> > Reading Kristofs compiler patch here: > https://reviews.llvm.org/rG195f44278c4361a4a32377a98a1e3a15203d3647 > > I take it that for affected CPUs we should also patch all assembly > in the kernel containing a RET, BR or BLR with > DSB SYS followed by ISB? > > I suppose we would also need to look for any mov PC, <> > code... > > I guess we can invent a "SB" macro to mimic what Aarch64 is > doing so the code is easy to read. (Thinking aloud.) > > Yours, > Linus Walleij
| |