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=-15.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,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 30F52C433DB for ; Wed, 17 Feb 2021 09:51:53 +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 BC33A64DF0 for ; Wed, 17 Feb 2021 09:51:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BC33A64DF0 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=kaSgZsn3by1YiweIvhb9Yc5N6XzcSyc3M5BoCtLx5xQ=; b=dTXpvrUd8icNJ9uf+cZAFxqKo HTtIkr07k1DWSpoPFQxg56NYmFUC0Nr+XKPfJIaivddhADlkDWN5dw54iMi5fLFsEZpoZ0O8PrpYO 861phtLpaqpNMkCCivh4fmp88Mm14K0Nx5ISW/GpfFhNKGvrNi0jFvJ//P+cN1yIgbtUQLJHQ5ztO KM5+DQkEPTOKPf7k1tmHBm3FGf14zgG3v9bItSsjzXpf6x2rLI4PXg2sEC5XO8fxd9bEispGGo+x6 PIyAqAIZ/ZD/tV6oDHgWDPOY2FUlcZR+/JSBiW2OYaT5pa2oUcRzN289pbIWk4ijPyjWDGfLu5K// oO2MsBDkw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lCJSO-0001xn-1e; Wed, 17 Feb 2021 09:49:16 +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 1lCJSH-0001xS-9o for linux-arm-kernel@lists.infradead.org; Wed, 17 Feb 2021 09:49:13 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id B9EEF64D9A; Wed, 17 Feb 2021 09:49:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1613555347; bh=Xt/pQSPwnxdeV+GK8xvNK5JorjBJhSGXtix1A7YYkHs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=cmHOlOJSrtLNdApKnF1/VctQ8ghvtak+WGJq46qyDCg5JefXgafmbZC9mDPfSd3KB rhv+okJgtmULUfVaMG8fgTlLK430NC94GnMK5If9O72D1lwBcaBhNbmP+9EWoL8g8w h1QTXkhPytla+f17A6on0yqlagF1AB9V/CzBtPpasiojS0pliXVG/OaXDjWY7DMSIx GgBX8fhfwU8RloN2syZjG7CaBizB5Yqc/cJjGsEC0OWGe+gpus6TUKIv1Ej17XKokh Aq16i9tFXzN1gNGaLRjiES3MHp3c3SXgDWimMtsZBfDFRkpvXyltTZThaaecwuq+eJ U92mKBijH3UdA== Date: Wed, 17 Feb 2021 09:49:00 +0000 From: Will Deacon To: Jian Cai Subject: Re: [PATCH v2] ARM: Implement Clang's SLS mitigation Message-ID: <20210217094859.GA3706@willie-the-truck> References: <3f61af0eee9b495e8e8c032902d033c5@AcuMS.aculab.com> <20210212195255.1321544-1-jiancai@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210212195255.1321544-1-jiancai@google.com> 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-20210217_044909_496197_642ADE26 X-CRM114-Status: GOOD ( 22.89 ) 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: linux-kernel@vger.kernel.org, Kees Cook , Arnd Bergmann , Catalin Marinas , Masahiro Yamada , ndesaulniers@google.com, Russell King , Krzysztof Kozlowski , James Morris , Nathan Chancellor , clang-built-linux@googlegroups.com, linux-security-module@vger.kernel.org, David Laight , manojgupta@google.com, Andreas =?iso-8859-1?Q?F=E4rber?= , llozano@google.com, Ard Biesheuvel , linux-arm-kernel@lists.infradead.org, "Serge E. Hallyn" 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 Fri, Feb 12, 2021 at 11:52:53AM -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. What exactly does this mitigation do? This should be documented somewhere, maybe in the Kconfig text? > Link: https://reviews.llvm.org/D93221 > Link: https://reviews.llvm.org/D81404 > Link: 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: Nathan Chancellor > Suggested-by: David Laight > Signed-off-by: Jian Cai > --- > > Changes v1 -> v2: > Update the description and patch based on Nathan and David's comments. > > arch/arm/Makefile | 4 ++++ > arch/arm64/Makefile | 4 ++++ > security/Kconfig.hardening | 7 +++++++ > 3 files changed, 15 insertions(+) > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > index 4aaec9599e8a..11d89ef32da9 100644 > --- a/arch/arm/Makefile > +++ b/arch/arm/Makefile > @@ -48,6 +48,10 @@ CHECKFLAGS += -D__ARMEL__ > KBUILD_LDFLAGS += -EL > endif > > +ifeq ($(CONFIG_HARDEN_SLS_ALL), y) > +KBUILD_CFLAGS += -mharden-sls=all > +endif > + > # > # The Scalar Replacement of Aggregates (SRA) optimization pass in GCC 4.9 and > # later may result in code being generated that handles signed short and signed > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile > index 90309208bb28..ca7299b356a9 100644 > --- a/arch/arm64/Makefile > +++ b/arch/arm64/Makefile > @@ -34,6 +34,10 @@ $(warning LSE atomics not supported by binutils) > endif > endif > > +ifeq ($(CONFIG_HARDEN_SLS_ALL), y) > +KBUILD_CFLAGS += -mharden-sls=all > +endif The big problem I have with this is that it's a compile-time decision. For the other spectre crap we have a combination of the "mitigations=off" command-line and CPU detection to avoid the cost of the mitigation where it is not deemed necessary. 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). 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? Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel