From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752103AbeAYMn4 convert rfc822-to-8bit (ORCPT ); Thu, 25 Jan 2018 07:43:56 -0500 Received: from smtp-out4.electric.net ([192.162.216.195]:54022 "EHLO smtp-out4.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752071AbeAYMny (ORCPT ); Thu, 25 Jan 2018 07:43:54 -0500 From: David Laight To: "'Will Deacon'" , Mark Salter CC: Marc Zyngier , Khuong Dinh , "linux-arm-kernel@lists.infradead.org" , "catalin.marinas@arm.com" , "jcm@redhat.com" , "lorenzo.pieralisi@arm.com" , "ard.biesheuvel@linaro.org" , "linux-kernel@vger.kernel.org" , "christoffer.dall@linaro.org" , "patches@apm.com" Subject: RE: [PATCH] arm64: turn off xgene branch prediction while in kernel space Thread-Topic: [PATCH] arm64: turn off xgene branch prediction while in kernel space Thread-Index: AQHTlTKUZVrNGkpW6UiZL00ACo1uxaOEiUrQ Date: Thu, 25 Jan 2018 12:44:34 +0000 Message-ID: <13f48247088a49b0a4a9afef0aa576a7@AcuMS.aculab.com> References: <1516760007-14670-1-git-send-email-kdinh@apm.com> <1516811703.2957.47.camel@redhat.com> <20180124164324.GA30462@arm.com> In-Reply-To: <20180124164324.GA30462@arm.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Outbound-IP: 156.67.243.126 X-Env-From: David.Laight@ACULAB.COM X-Proto: esmtps X-Revdns: X-HELO: AcuMS.aculab.com X-TLS: TLSv1.2:ECDHE-RSA-AES256-SHA384:256 X-Authenticated_ID: X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Will Deacon > Sent: 24 January 2018 16:43 > On Wed, Jan 24, 2018 at 11:35:03AM -0500, Mark Salter wrote: > > On Wed, 2018-01-24 at 10:58 +0000, Marc Zyngier wrote: > > > Khuong, > > > > > > On 24/01/18 02:13, Khuong Dinh wrote: > > > > Aliasing attacks against CPU branch predictors can allow an attacker to > > > > redirect speculative control flow on some CPUs and potentially divulge > > > > information from one context to another. > > > > > > > > This patch only supports for XGene processors. ... > > > Why isn't this using the infrastructure that is already in place? > > > > That infrastructure relies on a cpu-specific flush of the branch > > predictor. XGene does not have the ability to flush the branch > > predictor. It can only turn it on or off. > > So how does this patch protect one user application from another? Sounds > like you need to turn the thing off at boot and leave it that way, or find > a sequence of branch instructions to effectively do the invalidation. What sort of performance penalty does this give? I can imagine it is significant. Attempting to flush a branch predictor is also likely to be very slow. David From mboxrd@z Thu Jan 1 00:00:00 1970 From: David.Laight@ACULAB.COM (David Laight) Date: Thu, 25 Jan 2018 12:44:34 +0000 Subject: [PATCH] arm64: turn off xgene branch prediction while in kernel space In-Reply-To: <20180124164324.GA30462@arm.com> References: <1516760007-14670-1-git-send-email-kdinh@apm.com> <1516811703.2957.47.camel@redhat.com> <20180124164324.GA30462@arm.com> Message-ID: <13f48247088a49b0a4a9afef0aa576a7@AcuMS.aculab.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org From: Will Deacon > Sent: 24 January 2018 16:43 > On Wed, Jan 24, 2018 at 11:35:03AM -0500, Mark Salter wrote: > > On Wed, 2018-01-24 at 10:58 +0000, Marc Zyngier wrote: > > > Khuong, > > > > > > On 24/01/18 02:13, Khuong Dinh wrote: > > > > Aliasing attacks against CPU branch predictors can allow an attacker to > > > > redirect speculative control flow on some CPUs and potentially divulge > > > > information from one context to another. > > > > > > > > This patch only supports for XGene processors. ... > > > Why isn't this using the infrastructure that is already in place? > > > > That infrastructure relies on a cpu-specific flush of the branch > > predictor. XGene does not have the ability to flush the branch > > predictor. It can only turn it on or off. > > So how does this patch protect one user application from another? Sounds > like you need to turn the thing off at boot and leave it that way, or find > a sequence of branch instructions to effectively do the invalidation. What sort of performance penalty does this give? I can imagine it is significant. Attempting to flush a branch predictor is also likely to be very slow. David