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=-8.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 320D7C433E0 for ; Thu, 2 Jul 2020 07:23:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0C4C420884 for ; Thu, 2 Jul 2020 07:23:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593674591; bh=Re61RwD/CyQqWBiQskwnaPfGr1o4kLsu1CWsfLls+hM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=bC/8WfTBTYksU0+wuHpAbG+pJnEoNrqkBuHd91t8AY1HzsFQwFgva9LSoYY6YM7fT DfBjln6RSvzErRIR9az/KwyTfZnF+OKdCrDRQH25HSQG4lJfos05fbdcDjOUtW19E3 FTGrpZ4btl3YDphdbEqxlrmo+FRf8gP3Ipj6ELH4= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727977AbgGBHXJ (ORCPT ); Thu, 2 Jul 2020 03:23:09 -0400 Received: from mail.kernel.org ([198.145.29.99]:55862 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726362AbgGBHXJ (ORCPT ); Thu, 2 Jul 2020 03:23:09 -0400 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3B3D42073E; Thu, 2 Jul 2020 07:23:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593674588; bh=Re61RwD/CyQqWBiQskwnaPfGr1o4kLsu1CWsfLls+hM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kuS2Mmhm+7c/+nST2Wi4JbOT82ZSobqK5KFCdbVqQXwCGLZBy7/LpmgMb7Pq85t1G a6m6BrCh5id96wu1KUG0opwCahVKpnhDfkXuSg9AMslVdZ1XMgtrIMFp1PT5EHGsL9 n0XlU4lEskbMa3Pt2IwRkzphNfPJu+6WmVYkG9DQ= Date: Thu, 2 Jul 2020 08:23:02 +0100 From: Will Deacon To: Dave P Martin Cc: linux-kernel@vger.kernel.org, Mark Rutland , "Michael S. Tsirkin" , Peter Zijlstra , Catalin Marinas , Jason Wang , virtualization@lists.linux-foundation.org, Arnd Bergmann , Alan Stern , Sami Tolvanen , Matt Turner , kernel-team@android.com, Marco Elver , Kees Cook , "Paul E. McKenney" , Boqun Feng , Josh Triplett , Ivan Kokshaysky , linux-arm-kernel@lists.infradead.org, Richard Henderson , Nick Desaulniers , linux-alpha@vger.kernel.org Subject: Re: [PATCH 18/18] arm64: lto: Strengthen READ_ONCE() to acquire when CLANG_LTO=y Message-ID: <20200702072301.GA15963@willie-the-truck> References: <20200630173734.14057-1-will@kernel.org> <20200630173734.14057-19-will@kernel.org> <20200701170722.4rte5ssnmrn2uqzg@bakewell.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200701170722.4rte5ssnmrn2uqzg@bakewell.cambridge.arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 01, 2020 at 06:07:25PM +0100, Dave P Martin wrote: > On Tue, Jun 30, 2020 at 06:37:34PM +0100, Will Deacon wrote: > > When building with LTO, there is an increased risk of the compiler > > converting an address dependency headed by a READ_ONCE() invocation > > into a control dependency and consequently allowing for harmful > > reordering by the CPU. > > > > Ensure that such transformations are harmless by overriding the generic > > READ_ONCE() definition with one that provides acquire semantics when > > building with LTO. > > > > Signed-off-by: Will Deacon > > --- > > arch/arm64/include/asm/rwonce.h | 63 +++++++++++++++++++++++++++++++ > > arch/arm64/kernel/vdso/Makefile | 2 +- > > arch/arm64/kernel/vdso32/Makefile | 2 +- > > 3 files changed, 65 insertions(+), 2 deletions(-) > > create mode 100644 arch/arm64/include/asm/rwonce.h > > > > diff --git a/arch/arm64/include/asm/rwonce.h b/arch/arm64/include/asm/rwonce.h > > new file mode 100644 > > index 000000000000..515e360b01a1 > > --- /dev/null > > +++ b/arch/arm64/include/asm/rwonce.h > > @@ -0,0 +1,63 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +/* > > + * Copyright (C) 2020 Google LLC. > > + */ > > +#ifndef __ASM_RWONCE_H > > +#define __ASM_RWONCE_H > > + > > +#ifdef CONFIG_CLANG_LTO > > Don't we have a generic option for LTO that's not specific to Clang. /me looks at the LTO series some more Oh yeah, there's CONFIG_LTO which is selected by CONFIG_LTO_CLANG, which is the non-typoed version of the above. I can switch this to CONFIG_LTO. > Also, can you illustrate code that can only be unsafe with Clang LTO? I don't have a concrete example, but it's an ongoing concern over on the LTO thread [1], so I cooked this to show one way we could deal with it. The main concern is that the whole-program optimisations enabled by LTO may allow the compiler to enumerate possible values for a pointer at link time and replace an address dependency between two loads with a control dependency instead, defeating the dependency ordering within the CPU. We likely won't realise if/when this goes wrong, other than impossible to debug, subtle breakage that crops up seemingly randomly. Ideally, we'd be able to detect this sort of thing happening at build time, and perhaps even prevent it with compiler options or annotations, but none of that is close to being available and I'm keen to progress the LTO patches in the meantime because they are a requirement for CFI. Will [1] https://lore.kernel.org/r/20200624203200.78870-1-samitolvanen@google.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: Will Deacon Subject: Re: [PATCH 18/18] arm64: lto: Strengthen READ_ONCE() to acquire when CLANG_LTO=y Date: Thu, 2 Jul 2020 08:23:02 +0100 Message-ID: <20200702072301.GA15963@willie-the-truck> References: <20200630173734.14057-1-will@kernel.org> <20200630173734.14057-19-will@kernel.org> <20200701170722.4rte5ssnmrn2uqzg@bakewell.cambridge.arm.com> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593674588; bh=Re61RwD/CyQqWBiQskwnaPfGr1o4kLsu1CWsfLls+hM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kuS2Mmhm+7c/+nST2Wi4JbOT82ZSobqK5KFCdbVqQXwCGLZBy7/LpmgMb7Pq85t1G a6m6BrCh5id96wu1KUG0opwCahVKpnhDfkXuSg9AMslVdZ1XMgtrIMFp1PT5EHGsL9 n0XlU4lEskbMa3Pt2IwRkzphNfPJu+6WmVYkG9DQ= Content-Disposition: inline In-Reply-To: <20200701170722.4rte5ssnmrn2uqzg@bakewell.cambridge.arm.com> Sender: linux-alpha-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Dave P Martin Cc: linux-kernel@vger.kernel.org, Mark Rutland , "Michael S. Tsirkin" , Peter Zijlstra , Catalin Marinas , Jason Wang , virtualization@lists.linux-foundation.org, Arnd Bergmann , Alan Stern , Sami Tolvanen , Matt Turner , kernel-team@android.com, Marco Elver , Kees Cook , "Paul E. McKenney" , Boqun Feng , Josh Triplett , Ivan Kokshaysky , linux-arm-kernel@lists.infradead.org, Richard Henderson , Nick On Wed, Jul 01, 2020 at 06:07:25PM +0100, Dave P Martin wrote: > On Tue, Jun 30, 2020 at 06:37:34PM +0100, Will Deacon wrote: > > When building with LTO, there is an increased risk of the compiler > > converting an address dependency headed by a READ_ONCE() invocation > > into a control dependency and consequently allowing for harmful > > reordering by the CPU. > > > > Ensure that such transformations are harmless by overriding the generic > > READ_ONCE() definition with one that provides acquire semantics when > > building with LTO. > > > > Signed-off-by: Will Deacon > > --- > > arch/arm64/include/asm/rwonce.h | 63 +++++++++++++++++++++++++++++++ > > arch/arm64/kernel/vdso/Makefile | 2 +- > > arch/arm64/kernel/vdso32/Makefile | 2 +- > > 3 files changed, 65 insertions(+), 2 deletions(-) > > create mode 100644 arch/arm64/include/asm/rwonce.h > > > > diff --git a/arch/arm64/include/asm/rwonce.h b/arch/arm64/include/asm/rwonce.h > > new file mode 100644 > > index 000000000000..515e360b01a1 > > --- /dev/null > > +++ b/arch/arm64/include/asm/rwonce.h > > @@ -0,0 +1,63 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +/* > > + * Copyright (C) 2020 Google LLC. > > + */ > > +#ifndef __ASM_RWONCE_H > > +#define __ASM_RWONCE_H > > + > > +#ifdef CONFIG_CLANG_LTO > > Don't we have a generic option for LTO that's not specific to Clang. /me looks at the LTO series some more Oh yeah, there's CONFIG_LTO which is selected by CONFIG_LTO_CLANG, which is the non-typoed version of the above. I can switch this to CONFIG_LTO. > Also, can you illustrate code that can only be unsafe with Clang LTO? I don't have a concrete example, but it's an ongoing concern over on the LTO thread [1], so I cooked this to show one way we could deal with it. The main concern is that the whole-program optimisations enabled by LTO may allow the compiler to enumerate possible values for a pointer at link time and replace an address dependency between two loads with a control dependency instead, defeating the dependency ordering within the CPU. We likely won't realise if/when this goes wrong, other than impossible to debug, subtle breakage that crops up seemingly randomly. Ideally, we'd be able to detect this sort of thing happening at build time, and perhaps even prevent it with compiler options or annotations, but none of that is close to being available and I'm keen to progress the LTO patches in the meantime because they are a requirement for CFI. Will [1] https://lore.kernel.org/r/20200624203200.78870-1-samitolvanen@google.com 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=-8.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,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 05098C433E0 for ; Thu, 2 Jul 2020 07:24:22 +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 C61462073E for ; Thu, 2 Jul 2020 07:24:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="TtrCwWE5"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="kuS2Mmhm" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C61462073E 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=HGVDm+xJpcdthm9ypn1V7F60N8VT/Fg+/sIajNbfPCU=; b=TtrCwWE562xeRXWWhOjpfTeS2 GLiNb3lr3jAumZ0WrYidW/RMckNMUOaHOSBI5nd/GoUTSgsNZhmgG60PeisKkuewtzRQ5x2dLvY0P psVAv/Gy96MujBnae+aI7wmcIjVzGxxbYPvlX9XqPnEbKB2E974YhoBvLKsll4s2DP/VSgv/fCyAc MNWSvM41cOO6eJNKCVXNCtM98ixCtnkHtxVy8S4uYLAJ4veV4fQMUyqQbaw9HXivq634kV8IItxuL bmc/B437v3OSTHbOeCLgvPKd8ZnUip4dRf5f8N92PhbAuezoP6jBJlETKrKTjcPLitJOnG6LQCSD/ kChosNMKQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jqtYv-00070N-DN; Thu, 02 Jul 2020 07:23:13 +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 1jqtYs-0006zJ-50 for linux-arm-kernel@lists.infradead.org; Thu, 02 Jul 2020 07:23:11 +0000 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3B3D42073E; Thu, 2 Jul 2020 07:23:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593674588; bh=Re61RwD/CyQqWBiQskwnaPfGr1o4kLsu1CWsfLls+hM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kuS2Mmhm+7c/+nST2Wi4JbOT82ZSobqK5KFCdbVqQXwCGLZBy7/LpmgMb7Pq85t1G a6m6BrCh5id96wu1KUG0opwCahVKpnhDfkXuSg9AMslVdZ1XMgtrIMFp1PT5EHGsL9 n0XlU4lEskbMa3Pt2IwRkzphNfPJu+6WmVYkG9DQ= Date: Thu, 2 Jul 2020 08:23:02 +0100 From: Will Deacon To: Dave P Martin Subject: Re: [PATCH 18/18] arm64: lto: Strengthen READ_ONCE() to acquire when CLANG_LTO=y Message-ID: <20200702072301.GA15963@willie-the-truck> References: <20200630173734.14057-1-will@kernel.org> <20200630173734.14057-19-will@kernel.org> <20200701170722.4rte5ssnmrn2uqzg@bakewell.cambridge.arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200701170722.4rte5ssnmrn2uqzg@bakewell.cambridge.arm.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-20200702_032310_312947_2060BFF5 X-CRM114-Status: GOOD ( 24.72 ) 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 , "Michael S. Tsirkin" , Peter Zijlstra , Catalin Marinas , Jason Wang , virtualization@lists.linux-foundation.org, Arnd Bergmann , Alan Stern , Sami Tolvanen , Matt Turner , kernel-team@android.com, Marco Elver , Kees Cook , "Paul E. McKenney" , Boqun Feng , Josh Triplett , Ivan Kokshaysky , linux-arm-kernel@lists.infradead.org, Richard Henderson , Nick Desaulniers , linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org 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 Wed, Jul 01, 2020 at 06:07:25PM +0100, Dave P Martin wrote: > On Tue, Jun 30, 2020 at 06:37:34PM +0100, Will Deacon wrote: > > When building with LTO, there is an increased risk of the compiler > > converting an address dependency headed by a READ_ONCE() invocation > > into a control dependency and consequently allowing for harmful > > reordering by the CPU. > > > > Ensure that such transformations are harmless by overriding the generic > > READ_ONCE() definition with one that provides acquire semantics when > > building with LTO. > > > > Signed-off-by: Will Deacon > > --- > > arch/arm64/include/asm/rwonce.h | 63 +++++++++++++++++++++++++++++++ > > arch/arm64/kernel/vdso/Makefile | 2 +- > > arch/arm64/kernel/vdso32/Makefile | 2 +- > > 3 files changed, 65 insertions(+), 2 deletions(-) > > create mode 100644 arch/arm64/include/asm/rwonce.h > > > > diff --git a/arch/arm64/include/asm/rwonce.h b/arch/arm64/include/asm/rwonce.h > > new file mode 100644 > > index 000000000000..515e360b01a1 > > --- /dev/null > > +++ b/arch/arm64/include/asm/rwonce.h > > @@ -0,0 +1,63 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +/* > > + * Copyright (C) 2020 Google LLC. > > + */ > > +#ifndef __ASM_RWONCE_H > > +#define __ASM_RWONCE_H > > + > > +#ifdef CONFIG_CLANG_LTO > > Don't we have a generic option for LTO that's not specific to Clang. /me looks at the LTO series some more Oh yeah, there's CONFIG_LTO which is selected by CONFIG_LTO_CLANG, which is the non-typoed version of the above. I can switch this to CONFIG_LTO. > Also, can you illustrate code that can only be unsafe with Clang LTO? I don't have a concrete example, but it's an ongoing concern over on the LTO thread [1], so I cooked this to show one way we could deal with it. The main concern is that the whole-program optimisations enabled by LTO may allow the compiler to enumerate possible values for a pointer at link time and replace an address dependency between two loads with a control dependency instead, defeating the dependency ordering within the CPU. We likely won't realise if/when this goes wrong, other than impossible to debug, subtle breakage that crops up seemingly randomly. Ideally, we'd be able to detect this sort of thing happening at build time, and perhaps even prevent it with compiler options or annotations, but none of that is close to being available and I'm keen to progress the LTO patches in the meantime because they are a requirement for CFI. Will [1] https://lore.kernel.org/r/20200624203200.78870-1-samitolvanen@google.com _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel