linux-kernel - Re: [PATCH] arm64/fpsimd: Ensure that offlined CPUs are not using SME

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 18 Jun 2024 15:51:47 +0100
From: Mark Rutland <mark.rutland@....com>
To: Mark Brown <broonie@...nel.org>
Cc: Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64/fpsimd: Ensure that offlined CPUs are not using SME

On Tue, Jun 18, 2024 at 03:03:50PM +0100, Mark Brown wrote:
> When we use CPU hotplug to offline a CPU we may transition directly from
> running a task which was using SME to the CPU being offlined. This means
> that PSTATE.{SM,ZA} may still be set, indicating to the system that SME is
> still in use. This could create contention with other still running CPUs if
> the system uses shared SMCUs.

Does it actually cause contention if the CPU isn't issuing SME
instructions?

Is this theoretical or something you see in practice?

> For most systems this shouldn't be an issue, we should have PSCI or some
> other power management mechanism which will take care of this as part of
> offlining the CPU. However we do still have support for spin tables,

I don't think spin-table is relevant; there's no support whatsoever for
offlining CPUs with spin-table (and offlining will be rejected long
before cpu_die()).

> and it is possible that system firmware may not be ideally
> implemented, so let's explicitly disable SME during the process of
> offlining the CPU in order to ensure there's no spurious contention.

If this is an issue, surely it's the same with idle, or any other long
period spent in the kernel, or any long period where userspace leaves
the CPU in streaming mode?

It feels very odd that we should need to do something for cpu offlining
in particular.

Mark,

> Signed-off-by: Mark Brown <broonie@...nel.org>
> ---
>  arch/arm64/kernel/smp.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 31c8b3094dd7..9e8fc6ac758a 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -383,6 +383,10 @@ void __noreturn cpu_die(void)
>  	/* Tell cpuhp_bp_sync_dead() that this CPU is now safe to dispose of */
>  	cpuhp_ap_report_dead();
>  
> +	/* Ensure we are not spuriously contending any SMCU */
> +	if (system_supports_sme())
> +		sme_smstop();
> +
>  	/*
>  	 * Actually shutdown the CPU. This must never fail. The specific hotplug
>  	 * mechanism must perform all required cache maintenance to ensure that
> 
> ---
> base-commit: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670
> change-id: 20240617-arm64-fpsimd-sme-cpu-die-57205c7f220e
> 
> Best regards,
> -- 
> Mark Brown <broonie@...nel.org>
> 
>