lkml.org 
[lkml]   [2021]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v4] ARM: Implement SLS mitigation
    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.

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

    \
     
     \ /
      Last update: 2021-02-22 22:55    [W:2.564 / U:0.476 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site