Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752172AbeAEOsx (ORCPT + 1 other); Fri, 5 Jan 2018 09:48:53 -0500 Received: from foss.arm.com ([217.140.101.70]:45878 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752054AbeAEOsv (ORCPT ); Fri, 5 Jan 2018 09:48:51 -0500 Message-ID: <5A4F8FCD.3000903@arm.com> Date: Fri, 05 Jan 2018 14:46:37 +0000 From: James Morse User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0 MIME-Version: 1.0 To: Will Deacon , marc.zyngier@arm.com CC: linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, ard.biesheuvel@linaro.org, lorenzo.pieralisi@arm.com, christoffer.dall@linaro.org, linux-kernel@vger.kernel.org, labbott@redhat.com Subject: Re: [PATCH v2 11/11] arm64: Implement branch predictor hardening for affected Cortex-A CPUs References: <1515157961-20963-1-git-send-email-will.deacon@arm.com> <1515157961-20963-12-git-send-email-will.deacon@arm.com> In-Reply-To: <1515157961-20963-12-git-send-email-will.deacon@arm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: Hi Marc, Will, (SOB-chain suggests a missing From: tag on this and patch 7) On 05/01/18 13:12, Will Deacon wrote: > Cortex-A57, A72, A73 and A75 are susceptible to branch predictor aliasing > and can theoretically be attacked by malicious code. > > This patch implements a PSCI-based mitigation for these CPUs when available. > The call into firmware will invalidate the branch predictor state, preventing > any malicious entries from affecting other victim contexts. > > Signed-off-by: Marc Zyngier > Signed-off-by: Will Deacon > diff --git a/arch/arm64/kernel/bpi.S b/arch/arm64/kernel/bpi.S > index 06a931eb2673..2e9146534174 100644 > --- a/arch/arm64/kernel/bpi.S > +++ b/arch/arm64/kernel/bpi.S > @@ -53,3 +53,27 @@ ENTRY(__bp_harden_hyp_vecs_start) > vectors __kvm_hyp_vector > .endr > ENTRY(__bp_harden_hyp_vecs_end) > +ENTRY(__psci_hyp_bp_inval_start) > + sub sp, sp, #(8 * 18) Where does 18 come from? Isn't this storing 9 sets of 16 bytes? > + stp x16, x17, [sp, #(16 * 0)] > + stp x14, x15, [sp, #(16 * 1)] > + stp x12, x13, [sp, #(16 * 2)] > + stp x10, x11, [sp, #(16 * 3)] > + stp x8, x9, [sp, #(16 * 4)] > + stp x6, x7, [sp, #(16 * 5)] > + stp x4, x5, [sp, #(16 * 6)] > + stp x2, x3, [sp, #(16 * 7)] > + stp x0, x1, [sp, #(18 * 8)] 16->18 typo? > + mov x0, #0x84000000 > + smc #0 > + ldp x16, x17, [sp, #(16 * 0)] > + ldp x14, x15, [sp, #(16 * 1)] > + ldp x12, x13, [sp, #(16 * 2)] > + ldp x10, x11, [sp, #(16 * 3)] > + ldp x8, x9, [sp, #(16 * 4)] > + ldp x6, x7, [sp, #(16 * 5)] > + ldp x4, x5, [sp, #(16 * 6)] > + ldp x2, x3, [sp, #(16 * 7)] > + ldp x0, x1, [sp, #(18 * 8)] > + add sp, sp, #(8 * 18) (and here?) > +ENTRY(__psci_hyp_bp_inval_end) Thanks, James