From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6A606C433E0 for ; Tue, 23 Feb 2021 10:06:31 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 093AD64E3F for ; Tue, 23 Feb 2021 10:06:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 093AD64E3F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=vHEfaiAq5MTT9cgD09CkdxtgXRlQumHW7ALa1d3U73Q=; b=UTLz28B4UTLJvEpOL3jfldLcT XyRVQNORv6RiV0GWWsRA29mPaBpQvYtBPeoeq41aKd2JW0zCp8jLvEFpLWn/BtGh8lb71Fkz/Cfd4 ezQItF1WRe8d0MNNB06j2wvRKZ5ekp9qVGLcubBcJb39jGsg6bL5J230NgGuQNUTHjd33juJvXr4l pHAFBkav8CA/ze23r7gOlyxZR+2Ym0wgUXyU+jbTZ5YCCPMPxc0a+wFWKDyaTty+PR41WHm9uD9V+ TTQYVpjJ67WG/mEEa10vq8vbjvqov8JBC3DWSzQWAJ7LNZL6PPUb5kkloHM2DPevv86YcjvkFWuvp gwqxGEvYw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lEUZ0-0007LL-PU; Tue, 23 Feb 2021 10:05:06 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1lEUYw-0007Kj-VO for linux-arm-kernel@lists.infradead.org; Tue, 23 Feb 2021 10:05:04 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 389EE64E22; Tue, 23 Feb 2021 10:04:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1614074701; bh=Wei69MTAw3cAoHZzehtkt6nVDExu19SQg53rlhzIYkc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WZOqzYAfqkinjCDFARp7S1HJXXBR9/a5BpaM0vR+ODhDKzZDPfF/ye7XjKQMUez35 gNYf4tHz2dZXzh6zzeOdB4V3qV1z9r5sgXIXTCI0aO5M02BEsGDwODUFLCu1Lt0bOf 0DK9G68zNyFKRYC1hCUEsoWO6316kYRolzd+VXquDUZT8xx0YR4ZC9pYlEAwapnwSR iFZl+6xr5ZixbyOTXA4xJh9vWEFM0si3FfsI5NrErO2BOcvcjSnsbqxWi1qJke/gga uJI0eyUbRiuqihtgi0hZ2CyAWZ72G2AC/8FGKqtO9r7yqQCxJpGGZu4aJGwqnQT86v k3LlYOeONI6cg== Date: Tue, 23 Feb 2021 10:04:53 +0000 From: Will Deacon To: Jian Cai Subject: Re: [PATCH v4] ARM: Implement SLS mitigation Message-ID: <20210223100453.GB10254@willie-the-truck> References: <20210219201852.3213914-1-jiancai@google.com> <20210219230841.875875-1-jiancai@google.com> <20210222115816.GA8605@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210223_050503_186116_591C3D47 X-CRM114-Status: GOOD ( 34.33 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Catalin Marinas , Linus Walleij , James Morris , Manoj Gupta , Ingo Molnar , Marc Zyngier , Masahiro Yamada , Russell King , Ard Biesheuvel , clang-built-linux , Luis Lozano , David Brazdil , "Serge E. Hallyn" , Kees Cook , Arnd Bergmann , Nathan Chancellor , Linux ARM , Nick Desaulniers , Linux Kernel Mailing List , linux-security-module@vger.kernel.org, David Laight , James Morse , Andrew Morton , Andreas =?iso-8859-1?Q?F=E4rber?= , Mike Rapoport Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 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 > > > Suggested-by: Nick Desaulniers > > > Suggested-by: Nathan Chancellor > > > Suggested-by: David Laight > > > Suggested-by: Will Deacon > > > Reviewed-by: Nathan Chancellor > > > Signed-off-by: Jian Cai > > > --- > > > > 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