Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp3400349imm; Tue, 29 May 2018 06:41:07 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIQko11BSLOkBnsXAAQIeWA3YEnOCOy+Mr220Ujm+C3mJ837q69/GJ7Nyd6E58w0UUq+svm X-Received: by 2002:a17:902:bd93:: with SMTP id q19-v6mr9071485pls.342.1527601267499; Tue, 29 May 2018 06:41:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527601267; cv=none; d=google.com; s=arc-20160816; b=vAWc9Vhl8nvImSt2fhwrabY6jy9NF4KVxj+JJ6tO4Z9/b8DPCwuBwtcEnT+7UhVv3l YQG//gfpW1qP/3ARn0VPN9zWL2cda0F2JZf1HissU/7eKDz/V+xuu5Ft2z2xOMe7e5qm 5lSlVGb2VB5GKubdpX5PZtglaYD2xYcIm5LNWBOAYPhe5azSev7mZqJurM3Q+KHMzx+6 pLdfHzg3l9ySvuXrSZ4xeCaBDp70bC4dDIYx+iw+FvL73Te93C8MnKiVbCR6a+IqO53p vUSDD1nNbCSufWQyFwfTdYo7rlHvVCIGXwcCkflnR2E2bMDs1jqTx2Ei3McuUaX7Nevz 5s3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=GgNnMA5NakbS2KUghR3WIj+LHGhGJnRFzMow5t6lQl0=; b=mNRA4+mDd6s3MgrFGSMZh4wWNIYreXPrBAFx51iKGBey4KShjf5REPmoZzuTBVXhfv Xsh654ccpEJQEdbdHI8D6Vb1obcRoyZoV1sq+6OWAMZw8U1u1hwdrhB0YD6P5TsyE9yK ivk5HsMSISvfXeCIzPWxmM9j+sccrdNONTuKjwUwhYAJ5ao8srawrfjwTXVJiYabuJlH Reb9JZvvBAeW31iS/59zqRMlMbrlRq9OzAh90vISUulfckBOY43mySNuSL3Ol1VarCsw CfJPkXtgDvAmzF48DCPSpe/kd7iCSFHB0ldJrfsEdF08epUdQX+JD8IfskHPTORrmfpN /guA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d2-v6si22993017pgo.337.2018.05.29.06.40.22; Tue, 29 May 2018 06:41:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934573AbeE2NfY (ORCPT + 99 others); Tue, 29 May 2018 09:35:24 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:40570 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934136AbeE2NfT (ORCPT ); Tue, 29 May 2018 09:35:19 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8B42D80D; Tue, 29 May 2018 06:35:18 -0700 (PDT) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 34C4E3F557; Tue, 29 May 2018 06:35:16 -0700 (PDT) Date: Tue, 29 May 2018 14:35:13 +0100 From: Mark Rutland To: Marc Zyngier Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvmarm@lists.cs.columbia.edu, Will Deacon , Catalin Marinas , Thomas Gleixner , Andy Lutomirski , Kees Cook , Greg Kroah-Hartman , Christoffer Dall , Randy Dunlap , Dominik Brodowski , Julien Grall Subject: Re: [PATCH v2 08/17] arm64: ssbd: Restore mitigation status on CPU resume Message-ID: <20180529133510.xopxpmxf7ypjeksc@lakrids.cambridge.arm.com> References: <20180529121121.24927-1-marc.zyngier@arm.com> <20180529121121.24927-9-marc.zyngier@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180529121121.24927-9-marc.zyngier@arm.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 29, 2018 at 01:11:12PM +0100, Marc Zyngier wrote: > On a system where firmware can dynamically change the state of the > mitigation, the CPU will always come up with the mitigation enabled, > including when coming back from suspend. > > If the user has requested "no mitigation" via a command line option, > let's enforce it by calling into the firmware again to disable it. > > Similarily, for a resume from hibernate, the mitigation could have > been disabled by the boot kernel. Let's ensure that it is set > back on in that case. > > Signed-off-by: Marc Zyngier With teh fixup in swsusp_arch_suspend(), this looks good to me. FWIW: Reviewed-by: Mark Rutland Mark. > --- > arch/arm64/include/asm/cpufeature.h | 6 ++++++ > arch/arm64/kernel/cpu_errata.c | 2 +- > arch/arm64/kernel/hibernate.c | 11 +++++++++++ > arch/arm64/kernel/suspend.c | 8 ++++++++ > 4 files changed, 26 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h > index b0fc3224ce8a..55bc1f073bfb 100644 > --- a/arch/arm64/include/asm/cpufeature.h > +++ b/arch/arm64/include/asm/cpufeature.h > @@ -553,6 +553,12 @@ static inline int arm64_get_ssbd_state(void) > #endif > } > > +#ifdef CONFIG_ARM64_SSBD > +void arm64_set_ssbd_mitigation(bool state); > +#else > +static inline void arm64_set_ssbd_mitigation(bool state) {} > +#endif > + > #endif /* __ASSEMBLY__ */ > > #endif > diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c > index 2fef634e6953..2b9a31a6a16a 100644 > --- a/arch/arm64/kernel/cpu_errata.c > +++ b/arch/arm64/kernel/cpu_errata.c > @@ -303,7 +303,7 @@ void __init arm64_enable_wa2_handling(struct alt_instr *alt, > *updptr = cpu_to_le32(aarch64_insn_gen_nop()); > } > > -static void arm64_set_ssbd_mitigation(bool state) > +void arm64_set_ssbd_mitigation(bool state) > { > switch (psci_ops.conduit) { > case PSCI_CONDUIT_HVC: > diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c > index 1ec5f28c39fc..6b2686d54411 100644 > --- a/arch/arm64/kernel/hibernate.c > +++ b/arch/arm64/kernel/hibernate.c > @@ -313,6 +313,17 @@ int swsusp_arch_suspend(void) > > sleep_cpu = -EINVAL; > __cpu_suspend_exit(); > + > + /* > + * Just in case the boot kernel did turn the SSBD > + * mitigation off behind our back, let's set the state > + * to what we expect it to be. > + */ > + switch (arm64_get_ssbd_state()) { > + case ARM64_SSBD_FORCE_ENABLE: > + case ARM64_SSBD_KERNEL: > + arm64_set_ssbd_mitigation(true); > + } > } > > local_daif_restore(flags); > diff --git a/arch/arm64/kernel/suspend.c b/arch/arm64/kernel/suspend.c > index a307b9e13392..70c283368b64 100644 > --- a/arch/arm64/kernel/suspend.c > +++ b/arch/arm64/kernel/suspend.c > @@ -62,6 +62,14 @@ void notrace __cpu_suspend_exit(void) > */ > if (hw_breakpoint_restore) > hw_breakpoint_restore(cpu); > + > + /* > + * On resume, firmware implementing dynamic mitigation will > + * have turned the mitigation on. If the user has forcefully > + * disabled it, make sure their wishes are obeyed. > + */ > + if (arm64_get_ssbd_state() == ARM64_SSBD_FORCE_DISABLE) > + arm64_set_ssbd_mitigation(false); > } > > /* > -- > 2.14.2 >