linux-kernel - Re: [PATCH v2] arm64/sme: Move storage of reg_smidr to __cpuinfo_store

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 for Android: free password hash cracker in your pocket

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

Message-ID: <877c7ysois.wl-maz@kernel.org>
Date: Tue, 17 Dec 2024 08:27:07 +0000
From: Marc Zyngier <maz@...nel.org>
To: Mark Brown <broonie@...nel.org>
Cc: Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>,
	Peter Collingbourne <pcc@...gle.com>,
	Mark Rutland <mark.rutland@....com>,
	linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	stable@...r.kernel.org
Subject: Re: [PATCH v2] arm64/sme: Move storage of reg_smidr to __cpuinfo_store_cpu()

On Mon, 16 Dec 2024 22:09:57 +0000,
Mark Brown <broonie@...nel.org> wrote:
> 
> In commit 892f7237b3ff ("arm64: Delay initialisation of
> cpuinfo_arm64::reg_{zcr,smcr}") we moved access to ZCR, SMCR and SMIDR
> later in the boot process in order to ensure that we don't attempt to
> interact with them if SVE or SME is disabled on the command line.
> Unfortunately when initialising the boot CPU in init_cpu_features() we work
> on a copy of the struct cpuinfo_arm64 for the boot CPU used only during
> boot, not the percpu copy used by the sysfs code. The expectation of the
> feature identification code was that the ID registers would be read in
> __cpuinfo_store_cpu() and the values not modified by init_cpu_features().
> 
> The main reason for the original change was to avoid early accesses to
> ZCR on practical systems that were seen shipping with SVE reported in ID
> registers but traps enabled at EL3 and handled as fatal errors, SME was
> rolled in due to the similarity with SVE. Since then we have removed the
> early accesses to ZCR and SMCR in commits:
> 
>   abef0695f9665c3d ("arm64/sve: Remove ZCR pseudo register from cpufeature code")
>   391208485c3ad50f ("arm64/sve: Remove SMCR pseudo register from cpufeature code")
> 
> so only the SMIDR_EL1 part of the change remains. Since SMIDR_EL1 is
> only trapped via FEAT_IDST and not the SME trap it is less likely to be
> affected by similar issues, and the factors that lead to issues with SVE
> are less likely to apply to SME.
> 
> Since we have not yet seen practical SME systems that need to use a
> command line override (and are only just beginning to see SME systems at
> all) let's just remove the override and store SMIDR_EL1 along with all
> the other ID register reads in __cpuinfo_store_cpu().
> 
> This issue wasn't apparent when testing on emulated platforms that do not
> report values in SMIDR_EL1.
> 
> Fixes: 892f7237b3ff ("arm64: Delay initialisation of cpuinfo_arm64::reg_{zcr,smcr}")
> Signed-off-by: Mark Brown <broonie@...nel.org>
> Cc: stable@...r.kernel.org
> ---
> Changes in v2:
> - Move the ID register read back to __cpuinfo_store_cpu().
> - Remove the command line option for SME ID register override.
> - Link to v1: https://lore.kernel.org/r/20241214-arm64-fix-boot-cpu-smidr-v1-1-0745c40772dd@kernel.org

My reading of the thread was that we don't need to kill the
arm64.nosme option as SMIDR_EL1 wouldn't UNDEF, which is guaranteed if
SME is implemented at all.

What was needed in 6.0 is not there anymore, for all the reasons that
Mark outlined and that you have pasted in the above commit message.

The removal of the arm64.nosme option is still a possibility, but
that's absolutely distinct from fixing the problem at hand.

	M.

-- 
Without deviation from the norm, progress is not possible.