Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752417AbeADRON (ORCPT + 1 other); Thu, 4 Jan 2018 12:14:13 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:35330 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752227AbeADROK (ORCPT ); Thu, 4 Jan 2018 12:14:10 -0500 Subject: Re: [PATCH 11/11] arm64: Implement branch predictor hardening for affected Cortex-A CPUs To: Ard Biesheuvel , Will Deacon Cc: linux-arm-kernel@lists.infradead.org, Catalin Marinas , Lorenzo Pieralisi , Christoffer Dall , Linux Kernel Mailing List References: <1515078515-13723-1-git-send-email-will.deacon@arm.com> <1515078515-13723-12-git-send-email-will.deacon@arm.com> From: Marc Zyngier Organization: ARM Ltd Message-ID: Date: Thu, 4 Jan 2018 17:14:07 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On 04/01/18 16:31, Ard Biesheuvel wrote: > On 4 January 2018 at 15:08, 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 >> --- >> arch/arm64/kernel/bpi.S | 24 ++++++++++++++++++++++++ >> arch/arm64/kernel/cpu_errata.c | 42 ++++++++++++++++++++++++++++++++++++++++++ >> 2 files changed, 66 insertions(+) >> >> diff --git a/arch/arm64/kernel/bpi.S b/arch/arm64/kernel/bpi.S >> index 06a931eb2673..2b10d52a0321 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) >> + stp x0, x1, [sp, #-16]! >> + stp x2, x3, [sp, #-16]! >> + stp x4, x5, [sp, #-16]! >> + stp x6, x7, [sp, #-16]! >> + stp x8, x9, [sp, #-16]! >> + stp x10, x11, [sp, #-16]! >> + stp x12, x13, [sp, #-16]! >> + stp x14, x15, [sp, #-16]! >> + stp x16, x17, [sp, #-16]! >> + stp x18, x19, [sp, #-16]! > > Would it be better to update sp only once here? Maybe. I suppose that's quite uarch dependent, but worth trying. > Also, do x18 and x19 need to be preserved/restored here? My bad. I misread the SMCCC and though I needed to save it too. For the reference, the text says: "Registers X18-X30 and stack pointers SP_EL0 and SP_ELx are saved by the function that is called, and must be preserved over the SMC or HVC call." I'll amend the patch. Thanks, M. -- Jazz is not dead. It just smells funny...