On Thu, May 22, 2025 at 01:41:48PM -0700, Oliver Upton wrote:

Prior to commit e8cde32f111f ("arm64/cpufeatures/kvm: Add ARMv8.9 FEAT_ECBHB bits in ID_AA64MMFR1 register") KVM was erroneously masking FEAT_ECBHB from VMs, giving the perception that safe implementations are actually vulnerable to Spectre-BHB. And, after commit e403e8538359 ("arm64: errata: Assume that unknown CPUs _are_ vulnerable to Spectre BHB") guests are enabling the loop mitigation.

This broken virtual hardware is going to be around for some time, so do the ugly thing and check for revisions of Neoverse-V2 [1], Cortex-X3 [2], Cortex-A720 [3], and Neoverse-N3 [4] that are documented to have FEAT_ECBHB.

Cc: stable@vger.kernel.org Link: https://developer.arm.com/documentation/102375/0002 Link: https://developer.arm.com/documentation/101593/0102 Link: https://developer.arm.com/documentation/102530/0002 Link: https://developer.arm.com/documentation/107997/0001 Signed-off-by: Oliver Upton oliver.upton@linux.dev

---

I thoroughly hate this but the alternative of nuking these busted VMs isn't exactly popular...

arch/arm64/include/asm/cputype.h | 1 + arch/arm64/kernel/proton-pack.c | 16 ++++++++++++++++ 2 files changed, 17 insertions(+)

diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h index d1cc0571798b..5c6152e61cad 100644 --- a/arch/arm64/include/asm/cputype.h +++ b/arch/arm64/include/asm/cputype.h @@ -282,6 +282,7 @@ struct midr_range { #define MIDR_REV_RANGE(m, v, r_min, r_max) MIDR_RANGE(m, v, r_min, v, r_max) #define MIDR_REV(m, v, r) MIDR_RANGE(m, v, r, v, r) #define MIDR_ALL_VERSIONS(m) MIDR_RANGE(m, 0, 0, 0xf, 0xf) +#define MIDR_MIN_VERSION(m, v, r) MIDR_RANGE(m, v, r, 0xf, 0xf) static inline bool midr_is_cpu_model_range(u32 midr, u32 model, u32 rv_min, u32 rv_max) diff --git a/arch/arm64/kernel/proton-pack.c b/arch/arm64/kernel/proton-pack.c index b198dde79e59..3d00d4c22d58 100644 --- a/arch/arm64/kernel/proton-pack.c +++ b/arch/arm64/kernel/proton-pack.c @@ -962,8 +962,24 @@ static bool has_spectre_bhb_fw_mitigation(void) static bool supports_ecbhb(int scope) {

• static const struct midr_range spectre_ecbhb_list[] = {

• MIDR_MIN_VERSION(MIDR_NEOVERSE_V2, 0, 2),
  

• MIDR_MIN_VERSION(MIDR_CORTEX_X3, 1, 1),
  

• MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N3),
  

• MIDR_MIN_VERSION(MIDR_CORTEX_A720, 0, 1),
  

• {},
  

• }; u64 mmfr1;

• /*

• * Prior to commit e8cde32f111f ("arm64/cpufeatures/kvm: Add ARMv8.9
  

• * FEAT_ECBHB bits in ID_AA64MMFR1 register"), KVM masked FEAT_ECBHB
  

• * on implementations that actually have the feature. That sucks; infer
  

• * presence of FEAT_ECBHB based on MIDR.
  

• */
  

• if (is_midr_in_range_list(spectre_ecbhb_list))

• return true;
  

I really don't think we want to go down this route.

If finer grained control of the spectre mitigations is needed, I think extending the existing command-line options is probably the best bet rather then inferring behaviours based on the MIDR.

Will