All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, kvmarm@lists.cs.columbia.edu,
	Kees Cook <keescook@chromium.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Christoffer Dall <christoffer.dall@arm.com>,
	Andy Lutomirski <luto@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 08/14] arm64: ssbd: Disable mitigation on CPU resume if required by user
Date: Thu, 24 May 2018 12:55:38 +0100	[thread overview]
Message-ID: <20180524115538.iq2rfntxyfqmskom@lakrids.cambridge.arm.com> (raw)
In-Reply-To: <20180522150648.28297-9-marc.zyngier@arm.com>

On Tue, May 22, 2018 at 04:06:42PM +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.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
>  arch/arm64/include/asm/cpufeature.h | 6 ++++++
>  arch/arm64/kernel/cpu_errata.c      | 8 ++++----
>  arch/arm64/kernel/suspend.c         | 8 ++++++++
>  3 files changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> index 1bacdf57f0af..d9dcb683259e 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 8f686f39b9c1..b4c12e9140f0 100644
> --- a/arch/arm64/kernel/cpu_errata.c
> +++ b/arch/arm64/kernel/cpu_errata.c
> @@ -297,7 +297,7 @@ void __init arm64_enable_wa2_handling(struct alt_instr *alt,
>  		*updptr = cpu_to_le32(aarch64_insn_gen_nop());
>  }
>  
> -static void do_ssbd(bool state)
> +void arm64_set_ssbd_mitigation(bool state)

Using this name from the outset would be nice, if you're happy to fold
that earlier in the seires. Not a big deal either way.

>  {
>  	switch (psci_ops.conduit) {
>  	case PSCI_CONDUIT_HVC:
> @@ -371,20 +371,20 @@ static bool has_ssbd_mitigation(const struct arm64_cpu_capabilities *entry,
>  	switch (ssbd_state) {
>  	case ARM64_SSBD_FORCE_DISABLE:
>  		pr_info_once("%s disabled from command-line\n", entry->desc);
> -		do_ssbd(false);
> +		arm64_set_ssbd_mitigation(false);
>  		required = false;
>  		break;
>  
>  	case ARM64_SSBD_EL1_ENTRY:
>  		if (required) {
>  			__this_cpu_write(arm64_ssbd_callback_required, 1);
> -			do_ssbd(true);
> +			arm64_set_ssbd_mitigation(true);
>  		}
>  		break;
>  
>  	case ARM64_SSBD_FORCE_ENABLE:
>  		pr_info_once("%s forced from command-line\n", entry->desc);
> -		do_ssbd(true);
> +		arm64_set_ssbd_mitigation(true);
>  		required = true;
>  		break;
>  
> 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);
>  }

This looks fine for idle and suspend-to-ram, so:

Reviewed-by: Mark Rutland <mark.rutland@arm.com>

However, for suspend-to-disk (i.e hibernate), the kernel doing the
resume might have SSBD force-disabled, while this kernel (which has just
been resumed) wants it enabled.

I think we also need something in swsusp_arch_suspend(), right after the
call to __cpu_suspend_exit() to re-enable that.

Thanks,
Mark.

WARNING: multiple messages have this Message-ID (diff)
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 08/14] arm64: ssbd: Disable mitigation on CPU resume if required by user
Date: Thu, 24 May 2018 12:55:38 +0100	[thread overview]
Message-ID: <20180524115538.iq2rfntxyfqmskom@lakrids.cambridge.arm.com> (raw)
In-Reply-To: <20180522150648.28297-9-marc.zyngier@arm.com>

On Tue, May 22, 2018 at 04:06:42PM +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.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
>  arch/arm64/include/asm/cpufeature.h | 6 ++++++
>  arch/arm64/kernel/cpu_errata.c      | 8 ++++----
>  arch/arm64/kernel/suspend.c         | 8 ++++++++
>  3 files changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> index 1bacdf57f0af..d9dcb683259e 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 8f686f39b9c1..b4c12e9140f0 100644
> --- a/arch/arm64/kernel/cpu_errata.c
> +++ b/arch/arm64/kernel/cpu_errata.c
> @@ -297,7 +297,7 @@ void __init arm64_enable_wa2_handling(struct alt_instr *alt,
>  		*updptr = cpu_to_le32(aarch64_insn_gen_nop());
>  }
>  
> -static void do_ssbd(bool state)
> +void arm64_set_ssbd_mitigation(bool state)

Using this name from the outset would be nice, if you're happy to fold
that earlier in the seires. Not a big deal either way.

>  {
>  	switch (psci_ops.conduit) {
>  	case PSCI_CONDUIT_HVC:
> @@ -371,20 +371,20 @@ static bool has_ssbd_mitigation(const struct arm64_cpu_capabilities *entry,
>  	switch (ssbd_state) {
>  	case ARM64_SSBD_FORCE_DISABLE:
>  		pr_info_once("%s disabled from command-line\n", entry->desc);
> -		do_ssbd(false);
> +		arm64_set_ssbd_mitigation(false);
>  		required = false;
>  		break;
>  
>  	case ARM64_SSBD_EL1_ENTRY:
>  		if (required) {
>  			__this_cpu_write(arm64_ssbd_callback_required, 1);
> -			do_ssbd(true);
> +			arm64_set_ssbd_mitigation(true);
>  		}
>  		break;
>  
>  	case ARM64_SSBD_FORCE_ENABLE:
>  		pr_info_once("%s forced from command-line\n", entry->desc);
> -		do_ssbd(true);
> +		arm64_set_ssbd_mitigation(true);
>  		required = true;
>  		break;
>  
> 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);
>  }

This looks fine for idle and suspend-to-ram, so:

Reviewed-by: Mark Rutland <mark.rutland@arm.com>

However, for suspend-to-disk (i.e hibernate), the kernel doing the
resume might have SSBD force-disabled, while this kernel (which has just
been resumed) wants it enabled.

I think we also need something in swsusp_arch_suspend(), right after the
call to __cpu_suspend_exit() to re-enable that.

Thanks,
Mark.

  parent reply	other threads:[~2018-05-24 11:55 UTC|newest]

Thread overview: 109+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-22 15:06 [PATCH 00/14] arm64 SSBD (aka Spectre-v4) mitigation Marc Zyngier
2018-05-22 15:06 ` Marc Zyngier
2018-05-22 15:06 ` [PATCH 01/14] arm/arm64: smccc: Add SMCCC-specific return codes Marc Zyngier
2018-05-22 15:06   ` Marc Zyngier
2018-05-22 15:06   ` Marc Zyngier
2018-05-24 10:55   ` Mark Rutland
2018-05-24 10:55     ` Mark Rutland
2018-05-22 15:06 ` [PATCH 02/14] arm64: Call ARCH_WORKAROUND_2 on transitions between EL0 and EL1 Marc Zyngier
2018-05-22 15:06   ` Marc Zyngier
2018-05-22 15:06   ` Marc Zyngier
2018-05-23  9:23   ` Julien Grall
2018-05-23  9:23     ` Julien Grall
2018-05-24 10:52     ` Mark Rutland
2018-05-24 10:52       ` Mark Rutland
2018-05-24 12:10       ` Robin Murphy
2018-05-24 12:10         ` Robin Murphy
2018-05-24 11:00   ` Mark Rutland
2018-05-24 11:00     ` Mark Rutland
2018-05-24 11:23     ` Mark Rutland
2018-05-24 11:23       ` Mark Rutland
2018-05-24 11:28       ` Marc Zyngier
2018-05-24 11:28         ` Marc Zyngier
2018-05-22 15:06 ` [PATCH 03/14] arm64: Add per-cpu infrastructure to call ARCH_WORKAROUND_2 Marc Zyngier
2018-05-22 15:06   ` Marc Zyngier
2018-05-23 10:03   ` Julien Grall
2018-05-23 10:03     ` Julien Grall
2018-05-24 11:14   ` Mark Rutland
2018-05-24 11:14     ` Mark Rutland
2018-05-22 15:06 ` [PATCH 04/14] arm64: Add ARCH_WORKAROUND_2 probing Marc Zyngier
2018-05-22 15:06   ` Marc Zyngier
2018-05-22 15:06   ` Marc Zyngier
2018-05-23 10:06   ` Julien Grall
2018-05-23 10:06     ` Julien Grall
2018-05-24  9:58   ` Suzuki K Poulose
2018-05-24  9:58     ` Suzuki K Poulose
2018-05-24 11:39     ` Will Deacon
2018-05-24 11:39       ` Will Deacon
2018-05-24 13:34       ` Suzuki K Poulose
2018-05-24 13:34         ` Suzuki K Poulose
2018-05-24 11:27   ` Mark Rutland
2018-05-24 11:27     ` Mark Rutland
2018-05-22 15:06 ` [PATCH 05/14] arm64: Add 'ssbd' command-line option Marc Zyngier
2018-05-22 15:06   ` Marc Zyngier
2018-05-22 15:29   ` Randy Dunlap
2018-05-22 15:29     ` Randy Dunlap
2018-05-22 15:29     ` Randy Dunlap
2018-05-23 10:08   ` Julien Grall
2018-05-23 10:08     ` Julien Grall
2018-05-24 11:40   ` Mark Rutland
2018-05-24 11:40     ` Mark Rutland
2018-05-24 11:52     ` Marc Zyngier
2018-05-24 11:52       ` Marc Zyngier
2018-05-22 15:06 ` [PATCH 06/14] arm64: ssbd: Add global mitigation state accessor Marc Zyngier
2018-05-22 15:06   ` Marc Zyngier
2018-05-23 10:11   ` Julien Grall
2018-05-23 10:11     ` Julien Grall
2018-05-24 11:41   ` Mark Rutland
2018-05-24 11:41     ` Mark Rutland
2018-05-22 15:06 ` [PATCH 07/14] arm64: ssbd: Skip apply_ssbd if not using dynamic mitigation Marc Zyngier
2018-05-22 15:06   ` Marc Zyngier
2018-05-23 10:13   ` Julien Grall
2018-05-23 10:13     ` Julien Grall
2018-05-24 11:43   ` Mark Rutland
2018-05-24 11:43     ` Mark Rutland
2018-05-22 15:06 ` [PATCH 08/14] arm64: ssbd: Disable mitigation on CPU resume if required by user Marc Zyngier
2018-05-22 15:06   ` Marc Zyngier
2018-05-22 15:06   ` Marc Zyngier
2018-05-23 10:52   ` Julien Grall
2018-05-23 10:52     ` Julien Grall
2018-05-24 11:55   ` Mark Rutland [this message]
2018-05-24 11:55     ` Mark Rutland
2018-05-22 15:06 ` [PATCH 09/14] arm64: ssbd: Introduce thread flag to control userspace mitigation Marc Zyngier
2018-05-22 15:06   ` Marc Zyngier
2018-05-22 15:06   ` Marc Zyngier
2018-05-24 12:01   ` Mark Rutland
2018-05-24 12:01     ` Mark Rutland
2018-05-24 12:16     ` Marc Zyngier
2018-05-24 12:16       ` Marc Zyngier
2018-05-24 12:19       ` Will Deacon
2018-05-24 12:19         ` Will Deacon
2018-05-24 12:36         ` Marc Zyngier
2018-05-24 12:36           ` Marc Zyngier
2018-05-22 15:06 ` [PATCH 10/14] arm64: ssbd: Add prctl interface for per-thread mitigation Marc Zyngier
2018-05-22 15:06   ` Marc Zyngier
2018-05-22 15:48   ` Dominik Brodowski
2018-05-22 15:48     ` Dominik Brodowski
2018-05-22 16:30     ` Marc Zyngier
2018-05-22 16:30       ` Marc Zyngier
2018-05-22 16:30       ` Marc Zyngier
2018-05-24 12:10   ` Mark Rutland
2018-05-24 12:10     ` Mark Rutland
2018-05-24 12:24   ` Will Deacon
2018-05-24 12:24     ` Will Deacon
2018-05-22 15:06 ` [PATCH 11/14] arm64: KVM: Add HYP per-cpu accessors Marc Zyngier
2018-05-22 15:06   ` Marc Zyngier
2018-05-24 12:11   ` Mark Rutland
2018-05-24 12:11     ` Mark Rutland
2018-05-22 15:06 ` [PATCH 12/14] arm64: KVM: Add ARCH_WORKAROUND_2 support for guests Marc Zyngier
2018-05-22 15:06   ` Marc Zyngier
2018-05-24 12:15   ` Mark Rutland
2018-05-24 12:15     ` Mark Rutland
2018-05-22 15:06 ` [PATCH 13/14] arm64: KVM: Handle guest's ARCH_WORKAROUND_2 requests Marc Zyngier
2018-05-22 15:06   ` Marc Zyngier
2018-05-24 12:22   ` Mark Rutland
2018-05-24 12:22     ` Mark Rutland
2018-05-22 15:06 ` [PATCH 14/14] arm64: KVM: Add ARCH_WORKAROUND_2 discovery through ARCH_FEATURES_FUNC_ID Marc Zyngier
2018-05-22 15:06   ` Marc Zyngier
2018-05-24 12:25   ` Mark Rutland
2018-05-24 12:25     ` Mark Rutland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180524115538.iq2rfntxyfqmskom@lakrids.cambridge.arm.com \
    --to=mark.rutland@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=christoffer.dall@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=keescook@chromium.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=tglx@linutronix.de \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.