[PATCH 0/4] arm64: mitigate CVE-2024-7881 in the absence of firmware mitigation

[PATCH 0/4] arm64: mitigate CVE-2024-7881 in the absence of firmware mitigation

[Mark Rutland]

On some CPUs from Arm Ltd, it is possible for unprivileged code to cause
a hardware prefetcher to form an address using the contents of a memory
location which is accessible by privileged accesses in the active
translation regime, potentially leaking the contents of this memory
location via a side channel. This has been assigned CVE-2024-7881:

  https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-7881

Arm's recommended mitigation is that firmware configures an
IMPLEMENTATION DEFINED control bit (CPUACTLR6_EL1[41]) to disable the
affected prefetcher, and updates to Trusted Firmware-A are available to
do this. For systems which have not yet recevied a firmware update, KPTI
can help to mitigate the issue.

These patches enable KPTI for affected parts when the firmware
mitigation is not present. The presence of the mitigation is identified
by the presence of the SMCCC_ARCH_WORKAROUND_4 SMCCC call, which was
deployed with the mitigation. This is documented in the SMCCC 1.6 G BET0
specification:

  https://developer.arm.com/documentation/den0028/gbet0/?lang=en

I have tested this on a few configurations of virtual platforms. I'd
appreciate any feedback, especially on the KVM changes.

Mark.

Mark Rutland (4):
  arm64: cpufeature: rename unmap_kernel_at_el0() -> needs_kpti()
  arm64: cpufeature: factor out cpu_is_meltdown_safe()
  arm64: cpufeature: mitigate CVE-2024-7881
  KVM: arm64: expose SMCCC_ARCH_WORKAROUND_4 to guests

 arch/arm64/include/asm/spectre.h  |  2 +
 arch/arm64/include/uapi/asm/kvm.h |  4 ++
 arch/arm64/kernel/cpufeature.c    | 95 ++++++++++++++++++++++++-------
 arch/arm64/kvm/hypercalls.c       | 21 +++++++
 include/linux/arm-smccc.h         |  5 ++
 5 files changed, 107 insertions(+), 20 deletions(-)

-- 
2.30.2

[PATCH 1/4] arm64: cpufeature: rename unmap_kernel_at_el0() -> needs_kpti()

[Mark Rutland]

Most arm64_cpu_capabilities::matches callbacks are named to indicate
that they test a boolean condition, e.g. runs_at_el2() or
has_nested_virt_support(). This isn't clear for unmap_kernel_at_el0(),
which can be read as an action rather than a boolean condition, and it's
not immediately clear that this is related to KPTI.

Rename unmap_kernel_at_el0() to needs_kpti() to make this clearer.

There should be no functional change as a result of this patch.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
---
 arch/arm64/kernel/cpufeature.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 6ce71f444ed84..8fdcff3722696 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1758,8 +1758,7 @@ has_useable_cnp(const struct arm64_cpu_capabilities *entry, int scope)
 static bool __meltdown_safe = true;
 static int __kpti_forced; /* 0: not forced, >0: forced on, <0: forced off */
 
-static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
-				int scope)
+static bool needs_kpti(const struct arm64_cpu_capabilities *entry, int scope)
 {
 	/* List of CPUs that are not vulnerable and don't need KPTI */
 	static const struct midr_range kpti_safe_list[] = {
@@ -2545,11 +2544,10 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 		.capability = ARM64_UNMAP_KERNEL_AT_EL0,
 		.type = ARM64_CPUCAP_BOOT_RESTRICTED_CPU_LOCAL_FEATURE,
 		.cpu_enable = cpu_enable_kpti,
-		.matches = unmap_kernel_at_el0,
+		.matches = needs_kpti,
 		/*
-		 * The ID feature fields below are used to indicate that
-		 * the CPU doesn't need KPTI. See unmap_kernel_at_el0 for
-		 * more details.
+		 * The ID feature fields below are used to indicate that the
+		 * CPU doesn't need KPTI. See needs_kpti for more details.
 		 */
 		ARM64_CPUID_FIELDS(ID_AA64PFR0_EL1, CSV3, IMP)
 	},
-- 
2.30.2

[PATCH 2/4] arm64: cpufeature: factor out cpu_is_meltdown_safe()

[Mark Rutland]

Currently needs_kpti() checks whether a CPU is immune to meltdown. The
ID_AA64PFR0_EL1.CSV3 ID register field allows a CPU to self report that
it is immune, and kpti_safe_list contains CPUs which are known to be
immune but predate the existence of ID_AA64PFR0_EL1.CSV3.

In future there may be additional reasons to enable KPTI for a CPU
regardless of whether that CPU is immune to meltdown.

Factor out the existing meltdown checks into a new
cpu_is_meltdown_safe() helper function. The ID_AA64PFR0_EL1.CSV3 field
description is removed from the capability structure and made explicit
within cpu_is_meltdown_safe(). As needs_kpti() is only called with
SCOPE_LOCAL, this should not result in any functional change.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marins <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
---
 arch/arm64/kernel/cpufeature.c | 43 +++++++++++++++++++++-------------
 1 file changed, 27 insertions(+), 16 deletions(-)

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 8fdcff3722696..b746bb16ee785 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1755,13 +1755,12 @@ has_useable_cnp(const struct arm64_cpu_capabilities *entry, int scope)
 	return has_cpuid_feature(entry, scope);
 }
 
-static bool __meltdown_safe = true;
-static int __kpti_forced; /* 0: not forced, >0: forced on, <0: forced off */
-
-static bool needs_kpti(const struct arm64_cpu_capabilities *entry, int scope)
+static bool cpu_is_meltdown_safe(void)
 {
-	/* List of CPUs that are not vulnerable and don't need KPTI */
-	static const struct midr_range kpti_safe_list[] = {
+	u64 pfr0;
+
+	/* List of CPUs that are not vulnerable to meltdown */
+	static const struct midr_range meltdown_safe_list[] = {
 		MIDR_ALL_VERSIONS(MIDR_CAVIUM_THUNDERX2),
 		MIDR_ALL_VERSIONS(MIDR_BRCM_VULCAN),
 		MIDR_ALL_VERSIONS(MIDR_BRAHMA_B53),
@@ -1779,15 +1778,32 @@ static bool needs_kpti(const struct arm64_cpu_capabilities *entry, int scope)
 		MIDR_ALL_VERSIONS(MIDR_QCOM_KRYO_4XX_SILVER),
 		{ /* sentinel */ }
 	};
+
+	if (is_midr_in_range_list(read_cpuid_id(), meltdown_safe_list))
+		return true;
+
+	/*
+	 * ID_AA64PFR0_EL1.CSV3 > 0 indicates that this CPU is not vulnerable
+	 * to meltdown.
+	 */
+	pfr0 = __read_sysreg_by_encoding(SYS_ID_AA64PFR0_EL1);
+	if (cpuid_feature_extract_unsigned_field(pfr0, ID_AA64PFR0_EL1_CSV3_SHIFT))
+		return true;
+
+	return false;
+}
+
+static bool __meltdown_safe = true;
+static int __kpti_forced; /* 0: not forced, >0: forced on, <0: forced off */
+
+static bool needs_kpti(const struct arm64_cpu_capabilities *entry, int scope)
+{
 	char const *str = "kpti command line option";
 	bool meltdown_safe;
 
-	meltdown_safe = is_midr_in_range_list(read_cpuid_id(), kpti_safe_list);
-
-	/* Defer to CPU feature registers */
-	if (has_cpuid_feature(entry, scope))
-		meltdown_safe = true;
+	WARN_ON(scope != SCOPE_LOCAL_CPU);
 
+	meltdown_safe = cpu_is_meltdown_safe();
 	if (!meltdown_safe)
 		__meltdown_safe = false;
 
@@ -2545,11 +2561,6 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 		.type = ARM64_CPUCAP_BOOT_RESTRICTED_CPU_LOCAL_FEATURE,
 		.cpu_enable = cpu_enable_kpti,
 		.matches = needs_kpti,
-		/*
-		 * The ID feature fields below are used to indicate that the
-		 * CPU doesn't need KPTI. See needs_kpti for more details.
-		 */
-		ARM64_CPUID_FIELDS(ID_AA64PFR0_EL1, CSV3, IMP)
 	},
 	{
 		.capability = ARM64_HAS_FPSIMD,
-- 
2.30.2

[PATCH 3/4] arm64: cpufeature: mitigate CVE-2024-7881

[Mark Rutland]

On some CPUs from Arm Ltd, it is possible for unprivileged code to cause
a hardware prefetcher to form an address using the contents of a memory
location which is accessible by privileged accesses in the active
translation regime, potentially leaking the contents of this memory
location via a side channel. This has been assigned CVE-2024-7881:

  https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-7881

Arm's recommended mitigation is that firmware configures an
IMPLEMENTATION DEFINED control bit (CPUACTLR6_EL1[41]) to disable the
affected prefetcher, and updates to Trusted Firmware-A are available to
do this. Presence of the firmware mitigation is indicated by the
presence of a new SMCCC call, SMCCC_ARCH_WORKAROUND_4, which is
documented in the SMCCC 1.6 G BET0 specification:

  https://developer.arm.com/documentation/den0028/gbet0/?lang=en

Note that SMCCC_ARCH_WORKAROUND_4 has no return value, and exists solely
such that it can be detected via SMCCC_ARCH_FEATURES.

On systems which have not yet received a firmware update, enabling KPTI
will help to mitigate the issue. This patch enables KPTI on affected
parts where the lack of SMCCC_ARCH_WORKAROUND_4 indicates the absence of
the firmware workaround. This will implicitly disable SPE and/or TRBE if
either of these are present.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
---
 arch/arm64/kernel/cpufeature.c | 34 +++++++++++++++++++++++++++++++++-
 include/linux/arm-smccc.h      |  5 +++++
 2 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index b746bb16ee785..e90bf4dcb6f1c 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1793,6 +1793,35 @@ static bool cpu_is_meltdown_safe(void)
 	return false;
 }
 
+static bool cpu_has_leaky_prefetcher(void)
+{
+	struct arm_smccc_res res;
+
+	/* CPUs which are affected by CVE-2024-7881 */
+	static const struct midr_range leaky_prefetcher_list[] = {
+		MIDR_ALL_VERSIONS(MIDR_CORTEX_X3),
+		MIDR_ALL_VERSIONS(MIDR_CORTEX_X4),
+		MIDR_ALL_VERSIONS(MIDR_CORTEX_X925),
+		MIDR_ALL_VERSIONS(MIDR_NEOVERSE_V2),
+		MIDR_ALL_VERSIONS(MIDR_NEOVERSE_V3),
+		{ /* sentinel */ }
+	};
+
+	if (!is_midr_in_range_list(read_cpuid_id(), leaky_prefetcher_list))
+		return false;
+
+	/*
+	 * If ARCH_WORKAROUND_4 is implemented, then the firmware mitigation is
+	 * present. There is no need to call ARCH_WORKAROUND_4 itself.
+	 */
+	arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
+			     ARM_SMCCC_ARCH_WORKAROUND_4, &res);
+	if (res.a0 == SMCCC_RET_SUCCESS)
+		return false;
+
+	return true;
+}
+
 static bool __meltdown_safe = true;
 static int __kpti_forced; /* 0: not forced, >0: forced on, <0: forced off */
 
@@ -1800,6 +1829,7 @@ static bool needs_kpti(const struct arm64_cpu_capabilities *entry, int scope)
 {
 	char const *str = "kpti command line option";
 	bool meltdown_safe;
+	bool prefetcher_safe;
 
 	WARN_ON(scope != SCOPE_LOCAL_CPU);
 
@@ -1807,6 +1837,8 @@ static bool needs_kpti(const struct arm64_cpu_capabilities *entry, int scope)
 	if (!meltdown_safe)
 		__meltdown_safe = false;
 
+	prefetcher_safe = !cpu_has_leaky_prefetcher();
+
 	/*
 	 * For reasons that aren't entirely clear, enabling KPTI on Cavium
 	 * ThunderX leads to apparent I-cache corruption of kernel text, which
@@ -1846,7 +1878,7 @@ static bool needs_kpti(const struct arm64_cpu_capabilities *entry, int scope)
 		return __kpti_forced > 0;
 	}
 
-	return !meltdown_safe;
+	return !meltdown_safe || !prefetcher_safe;
 }
 
 static bool has_nv1(const struct arm64_cpu_capabilities *entry, int scope)
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index 67f6fdf2e7cd8..e77103ab2adfd 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -100,6 +100,11 @@
 			   ARM_SMCCC_SMC_32,				\
 			   0, 0x3fff)
 
+#define ARM_SMCCC_ARCH_WORKAROUND_4					\
+	ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL,				\
+			   ARM_SMCCC_SMC_32,				\
+			   0, 0x0004)
+
 #define ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID				\
 	ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL,				\
 			   ARM_SMCCC_SMC_32,				\
-- 
2.30.2

[PATCH 4/4] KVM: arm64: expose SMCCC_ARCH_WORKAROUND_4 to guests

[Mark Rutland]

Wire up KVM support so that guests can detect the presence of
SMCCC_ARCH_WORKAROUND_4 and determine whether firmware has mitigated
CVE-2024-7881.

SMCCC_ARCH_WORKAROUND_4 is documented in the SMCCC 1.6 G BET0
specification, which can be found at:

  https://developer.arm.com/documentation/den0028/gbet0/?lang=en

Note that SMCCC_ARCH_WORKAROUND_4 has no return value, and exists solely
such that it can be detected via SMCCC_ARCH_FEATURES.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Joey Gouly <joey.gouly@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Oliver Upton <oliver.upton@linux.dev>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Zenghui Yu <yuzenghui@huawei.com>
Cc: kvmarm@lists.linux.dev
---
 arch/arm64/include/asm/spectre.h  |  2 ++
 arch/arm64/include/uapi/asm/kvm.h |  4 ++++
 arch/arm64/kernel/cpufeature.c    | 14 ++++++++++++++
 arch/arm64/kvm/hypercalls.c       | 21 +++++++++++++++++++++
 4 files changed, 41 insertions(+)

diff --git a/arch/arm64/include/asm/spectre.h b/arch/arm64/include/asm/spectre.h
index 0c4d9045c31f4..365e5d7199f90 100644
--- a/arch/arm64/include/asm/spectre.h
+++ b/arch/arm64/include/asm/spectre.h
@@ -95,6 +95,8 @@ void spectre_v4_enable_task_mitigation(struct task_struct *tsk);
 
 enum mitigation_state arm64_get_meltdown_state(void);
 
+enum mitigation_state arm64_get_cve_2024_7881_state(void);
+
 enum mitigation_state arm64_get_spectre_bhb_state(void);
 bool is_spectre_bhb_affected(const struct arm64_cpu_capabilities *entry, int scope);
 u8 spectre_bhb_loop_affected(int scope);
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 66736ff04011e..aa207c633b115 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -304,6 +304,10 @@ struct kvm_arm_counter_offset {
 #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_3_AVAIL		1
 #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_3_NOT_REQUIRED	2
 
+#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_4	KVM_REG_ARM_FW_REG(4)
+#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_4_NOT_AVAIL		0
+#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_4_AVAIL		1
+
 /* SVE registers */
 #define KVM_REG_ARM64_SVE		(0x15 << KVM_REG_ARM_COPROC_SHIFT)
 
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index e90bf4dcb6f1c..50536abcdfac3 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1823,6 +1823,7 @@ static bool cpu_has_leaky_prefetcher(void)
 }
 
 static bool __meltdown_safe = true;
+static bool __leaky_prefetch_safe = true;
 static int __kpti_forced; /* 0: not forced, >0: forced on, <0: forced off */
 
 static bool needs_kpti(const struct arm64_cpu_capabilities *entry, int scope)
@@ -1838,6 +1839,8 @@ static bool needs_kpti(const struct arm64_cpu_capabilities *entry, int scope)
 		__meltdown_safe = false;
 
 	prefetcher_safe = !cpu_has_leaky_prefetcher();
+	if (!prefetcher_safe)
+		__leaky_prefetch_safe = false;
 
 	/*
 	 * For reasons that aren't entirely clear, enabling KPTI on Cavium
@@ -3945,3 +3948,14 @@ ssize_t cpu_show_meltdown(struct device *dev, struct device_attribute *attr,
 		return sprintf(buf, "Vulnerable\n");
 	}
 }
+
+enum mitigation_state arm64_get_cve_2024_7881_state(void)
+{
+	if (__leaky_prefetch_safe)
+		return SPECTRE_UNAFFECTED;
+
+	if (arm64_kernel_unmapped_at_el0())
+		return SPECTRE_MITIGATED;
+
+	return SPECTRE_VULNERABLE;
+}
diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
index 27ce4cb449049..876e6f29a73e0 100644
--- a/arch/arm64/kvm/hypercalls.c
+++ b/arch/arm64/kvm/hypercalls.c
@@ -337,6 +337,16 @@ int kvm_smccc_call_handler(struct kvm_vcpu *vcpu)
 				break;
 			}
 			break;
+		case ARM_SMCCC_ARCH_WORKAROUND_4:
+			switch (arm64_get_cve_2024_7881_state()) {
+			case SPECTRE_UNAFFECTED:
+				val[0] = SMCCC_RET_SUCCESS;
+				break;
+			case SPECTRE_VULNERABLE:
+			case SPECTRE_MITIGATED:
+				break;
+			}
+			break;
 		case ARM_SMCCC_HV_PV_TIME_FEATURES:
 			if (test_bit(KVM_REG_ARM_STD_HYP_BIT_PV_TIME,
 				     &smccc_feat->std_hyp_bmap))
@@ -387,6 +397,7 @@ static const u64 kvm_arm_fw_reg_ids[] = {
 	KVM_REG_ARM_STD_BMAP,
 	KVM_REG_ARM_STD_HYP_BMAP,
 	KVM_REG_ARM_VENDOR_HYP_BMAP,
+	KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_4,
 };
 
 void kvm_arm_init_hypercalls(struct kvm *kvm)
@@ -468,6 +479,14 @@ static int get_kernel_wa_level(struct kvm_vcpu *vcpu, u64 regid)
 			return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_3_NOT_REQUIRED;
 		}
 		return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_3_NOT_AVAIL;
+	case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_4:
+		switch (arm64_get_cve_2024_7881_state()) {
+		case SPECTRE_VULNERABLE:
+		case SPECTRE_MITIGATED:
+			return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_4_NOT_AVAIL;
+		case SPECTRE_UNAFFECTED:
+			return KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_4_AVAIL;
+		}
 	}
 
 	return -EINVAL;
@@ -486,6 +505,7 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 	case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
 	case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
 	case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_3:
+	case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_4:
 		val = get_kernel_wa_level(vcpu, reg->id) & KVM_REG_FEATURE_LEVEL_MASK;
 		break;
 	case KVM_REG_ARM_STD_BMAP:
@@ -587,6 +607,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 
 	case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
 	case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_3:
+	case KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_4:
 		if (val & ~KVM_REG_FEATURE_LEVEL_MASK)
 			return -EINVAL;
 
-- 
2.30.2

Re: [PATCH 0/4] arm64: mitigate CVE-2024-7881 in the absence of firmware mitigation

[Oliver Upton]

Hi Mark,

On Tue, Jan 28, 2025 at 03:54:24PM +0000, Mark Rutland wrote:
> On some CPUs from Arm Ltd, it is possible for unprivileged code to cause
> a hardware prefetcher to form an address using the contents of a memory
> location which is accessible by privileged accesses in the active
> translation regime, potentially leaking the contents of this memory
> location via a side channel. This has been assigned CVE-2024-7881:
> 
>   https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-7881
> 
> Arm's recommended mitigation is that firmware configures an
> IMPLEMENTATION DEFINED control bit (CPUACTLR6_EL1[41]) to disable the
> affected prefetcher, and updates to Trusted Firmware-A are available to
> do this. For systems which have not yet recevied a firmware update, KPTI
> can help to mitigate the issue.
> 
> These patches enable KPTI for affected parts when the firmware
> mitigation is not present. The presence of the mitigation is identified
> by the presence of the SMCCC_ARCH_WORKAROUND_4 SMCCC call, which was
> deployed with the mitigation. This is documented in the SMCCC 1.6 G BET0
> specification:
> 
>   https://developer.arm.com/documentation/den0028/gbet0/?lang=en
> 
> I have tested this on a few configurations of virtual platforms. I'd
> appreciate any feedback, especially on the KVM changes.

The KVM changes look reasonable and follow the usual model for this
crud. It would be nice to report the mitigation state to userspace
somehow as I would like to have a KVM selftest for all of the hardware
vulnerabilities.

But anyway,

Reviewed-by: Oliver Upton <oliver.upton@linux.dev>

-- 
Thanks,
Oliver

Re: [PATCH 0/4] arm64: mitigate CVE-2024-7881 in the absence of firmware mitigation

[Mark Rutland]

On Thu, Jan 30, 2025 at 01:48:53PM -0800, Oliver Upton wrote:
> Hi Mark,
> 
> On Tue, Jan 28, 2025 at 03:54:24PM +0000, Mark Rutland wrote:
> > On some CPUs from Arm Ltd, it is possible for unprivileged code to cause
> > a hardware prefetcher to form an address using the contents of a memory
> > location which is accessible by privileged accesses in the active
> > translation regime, potentially leaking the contents of this memory
> > location via a side channel. This has been assigned CVE-2024-7881:
> > 
> >   https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-7881
> > 
> > Arm's recommended mitigation is that firmware configures an
> > IMPLEMENTATION DEFINED control bit (CPUACTLR6_EL1[41]) to disable the
> > affected prefetcher, and updates to Trusted Firmware-A are available to
> > do this. For systems which have not yet recevied a firmware update, KPTI
> > can help to mitigate the issue.
> > 
> > These patches enable KPTI for affected parts when the firmware
> > mitigation is not present. The presence of the mitigation is identified
> > by the presence of the SMCCC_ARCH_WORKAROUND_4 SMCCC call, which was
> > deployed with the mitigation. This is documented in the SMCCC 1.6 G BET0
> > specification:
> > 
> >   https://developer.arm.com/documentation/den0028/gbet0/?lang=en
> > 
> > I have tested this on a few configurations of virtual platforms. I'd
> > appreciate any feedback, especially on the KVM changes.
> 
> The KVM changes look reasonable and follow the usual model for this
> crud. It would be nice to report the mitigation state to userspace
> somehow as I would like to have a KVM selftest for all of the hardware
> vulnerabilities.

Lemme go figure that out. Just to check, do you mean exposed through a
KVM mechanism, or under /sys/devices/system/cpu/vulnerabilities/ ? I
assume the latter.

> But anyway,
> 
> Reviewed-by: Oliver Upton <oliver.upton@linux.dev>

Thanks; much appreciated!

Mark.

Re: [PATCH 0/4] arm64: mitigate CVE-2024-7881 in the absence of firmware mitigation

[Oliver Upton]

On Fri, Jan 31, 2025 at 11:01:38AM +0000, Mark Rutland wrote:
> On Thu, Jan 30, 2025 at 01:48:53PM -0800, Oliver Upton wrote:
> > Hi Mark,
> > 
> > On Tue, Jan 28, 2025 at 03:54:24PM +0000, Mark Rutland wrote:
> > > On some CPUs from Arm Ltd, it is possible for unprivileged code to cause
> > > a hardware prefetcher to form an address using the contents of a memory
> > > location which is accessible by privileged accesses in the active
> > > translation regime, potentially leaking the contents of this memory
> > > location via a side channel. This has been assigned CVE-2024-7881:
> > > 
> > >   https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-7881
> > > 
> > > Arm's recommended mitigation is that firmware configures an
> > > IMPLEMENTATION DEFINED control bit (CPUACTLR6_EL1[41]) to disable the
> > > affected prefetcher, and updates to Trusted Firmware-A are available to
> > > do this. For systems which have not yet recevied a firmware update, KPTI
> > > can help to mitigate the issue.
> > > 
> > > These patches enable KPTI for affected parts when the firmware
> > > mitigation is not present. The presence of the mitigation is identified
> > > by the presence of the SMCCC_ARCH_WORKAROUND_4 SMCCC call, which was
> > > deployed with the mitigation. This is documented in the SMCCC 1.6 G BET0
> > > specification:
> > > 
> > >   https://developer.arm.com/documentation/den0028/gbet0/?lang=en
> > > 
> > > I have tested this on a few configurations of virtual platforms. I'd
> > > appreciate any feedback, especially on the KVM changes.
> > 
> > The KVM changes look reasonable and follow the usual model for this
> > crud. It would be nice to report the mitigation state to userspace
> > somehow as I would like to have a KVM selftest for all of the hardware
> > vulnerabilities.
> 
> Lemme go figure that out. Just to check, do you mean exposed through a
> KVM mechanism, or under /sys/devices/system/cpu/vulnerabilities/ ? I
> assume the latter.

Yep, the latter. Google has a test out of tree that checks the pseudo-FW
registers, hypercalls, and guest ID registers against what's in sysfs.

-- 
Thanks,
Oliver

Re: [PATCH 0/4] arm64: mitigate CVE-2024-7881 in the absence of firmware mitigation

[Catalin Marinas]

On Tue, 28 Jan 2025 15:54:24 +0000, Mark Rutland wrote:
> On some CPUs from Arm Ltd, it is possible for unprivileged code to cause
> a hardware prefetcher to form an address using the contents of a memory
> location which is accessible by privileged accesses in the active
> translation regime, potentially leaking the contents of this memory
> location via a side channel. This has been assigned CVE-2024-7881:
> 
>   https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-7881
> 
> [...]

Applied to arm64 (for-next/leaky-prefetcher), thanks!

There hasn't been much review (thanks Oliver for looking at the KVM
bits) and there's some implied work that can go on top of this series.
But the patches looked fine to me, so I queued them. Mark or others,
please shout if you'd like them dropped, they are on a branch.

[1/4] arm64: cpufeature: rename unmap_kernel_at_el0() -> needs_kpti()
      https://git.kernel.org/arm64/c/174ade921138
[2/4] arm64: cpufeature: factor out cpu_is_meltdown_safe()
      https://git.kernel.org/arm64/c/f4fe70cd8522
[3/4] arm64: cpufeature: mitigate CVE-2024-7881
      https://git.kernel.org/arm64/c/837dfd070e94
[4/4] KVM: arm64: expose SMCCC_ARCH_WORKAROUND_4 to guests
      https://git.kernel.org/arm64/c/d2c173acbf93

-- 
Catalin

Re: [PATCH 0/4] arm64: mitigate CVE-2024-7881 in the absence of firmware mitigation

[Will Deacon]

On Fri, Mar 14, 2025 at 06:37:25PM +0000, Catalin Marinas wrote:
> On Tue, 28 Jan 2025 15:54:24 +0000, Mark Rutland wrote:
> > On some CPUs from Arm Ltd, it is possible for unprivileged code to cause
> > a hardware prefetcher to form an address using the contents of a memory
> > location which is accessible by privileged accesses in the active
> > translation regime, potentially leaking the contents of this memory
> > location via a side channel. This has been assigned CVE-2024-7881:
> > 
> >   https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-7881
> > 
> > [...]
> 
> Applied to arm64 (for-next/leaky-prefetcher), thanks!
> 
> There hasn't been much review (thanks Oliver for looking at the KVM
> bits) and there's some implied work that can go on top of this series.
> But the patches looked fine to me, so I queued them. Mark or others,
> please shout if you'd like them dropped, they are on a branch.

I'm really not comfortable with this series and would prefer to see it
dropped while we continue the discussion, especially as it's causing
minor conflicts with the KVM/arm64 tree in -next.

The series is pitched a bit like an erratum workaround, but the overall
problem that a memory-dependent prefetcher can bypass permission checks
is fairly general and, even if nobody else gets this wrong, I doubt that
it's the last time Arm will mess it up. So, while the EL3 mitigation may
be Arm-specific, I don't think the rest of it really is. That's
especially true given the sorry state of spectre mitigations on
third-party derivatives of Arm designs, such as the Qualcomm Kryo parts,
and the fact that we provide userspace with a mechanism today for
querying the state of those mitigations via sysfs.

The immediate question, then, is whether this broken behaviour is
prohibited by CSV3. The text in the latest Arm ARM just refers to
"Data loaded under speculation", so it's not entirely clear whether that
applies to a prefetcher. If it *does*, then I can see the argument for
treating this like an erratum, but then we should zap CSV3 and treat
these parts as being affected by meltdown. On the other hand, if CSV3
is not intended to cover these prefetchers, then we probably need to
add a new "CVE-2024-7881" entry to /sys/devices/system/cpu/vulnerabilities.

As it stands with this patch series, userspace has no way to know about
the problem. kpti gets silently enabled in dmesg:

  | CPU features: detected: Kernel page table isolation (KPTI)

but the contents of the vulnerabilities directory is pretty misleading:

  gather_data_sampling: Not affected
  ghostwrite: Not affected
  itlb_multihit: Not affected
  l1tf: Not affected
  mds: Not affected
  meltdown: Not affected
  mmio_stale_data: Not affected
  reg_file_data_sampling: Not affected
  retbleed: Not affected
  spec_rstack_overflow: Not affected
  spec_store_bypass: Mitigation: Speculative Store Bypass disabled via prctl
  spectre_v1: Mitigation: __user pointer sanitization
  spectre_v2: Mitigation: CSV2, BHB
  srbds: Not affected
  tsx_async_abort: Not affected

The meltdown entry doesn't even mention that KPTI has been enabled.

If we decide to go with a new entry for this, then we also need to
change the default behaviour along the lines of Doug's Spectre-BHB
changes queued on for-next/spectre-bhb-assume-vulnerable so that we
assume vulnerable if we don't know better. To do otherwise will result
in false assurances to userspace on derivative and third-party
implementations.

To be clear: I'm not at all against mitigating this problem and
advertising the status of that mitigation. I *am* against quietly
handling it like a CPU erratum whilst simultaneously telling userspace
that meltdown is not a problem regardless of the mitigation state.

Will

Re: [PATCH 0/4] arm64: mitigate CVE-2024-7881 in the absence of firmware mitigation

[Oliver Upton]

On Mon, Mar 17, 2025 at 09:26:12PM +0000, Will Deacon wrote:
> On Fri, Mar 14, 2025 at 06:37:25PM +0000, Catalin Marinas wrote:
> > On Tue, 28 Jan 2025 15:54:24 +0000, Mark Rutland wrote:
> > > On some CPUs from Arm Ltd, it is possible for unprivileged code to cause
> > > a hardware prefetcher to form an address using the contents of a memory
> > > location which is accessible by privileged accesses in the active
> > > translation regime, potentially leaking the contents of this memory
> > > location via a side channel. This has been assigned CVE-2024-7881:
> > > 
> > >   https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-7881
> > > 
> > > [...]
> > 
> > Applied to arm64 (for-next/leaky-prefetcher), thanks!
> > 
> > There hasn't been much review (thanks Oliver for looking at the KVM
> > bits) and there's some implied work that can go on top of this series.
> > But the patches looked fine to me, so I queued them. Mark or others,
> > please shout if you'd like them dropped, they are on a branch.
> 
> I'm really not comfortable with this series and would prefer to see it
> dropped while we continue the discussion, especially as it's causing
> minor conflicts with the KVM/arm64 tree in -next.

Catalin, unless you say otherwise, I'm going to assume this will be
dropped in the interim.

> The series is pitched a bit like an erratum workaround, but the overall
> problem that a memory-dependent prefetcher can bypass permission checks
> is fairly general and, even if nobody else gets this wrong, I doubt that
> it's the last time Arm will mess it up. So, while the EL3 mitigation may
> be Arm-specific, I don't think the rest of it really is. That's
> especially true given the sorry state of spectre mitigations on
> third-party derivatives of Arm designs, such as the Qualcomm Kryo parts,
> and the fact that we provide userspace with a mechanism today for
> querying the state of those mitigations via sysfs.
> 
> The immediate question, then, is whether this broken behaviour is
> prohibited by CSV3. The text in the latest Arm ARM just refers to
> "Data loaded under speculation", so it's not entirely clear whether that
> applies to a prefetcher.

Hmm, good point. I think prefetchers fall under the ARM ARM glossary
definition of speculation, which includes:

 - Operations generated by the hardware that are not directly generated
   by any instructions appearing in the Execution stream.

> If we decide to go with a new entry for this, then we also need to
> change the default behaviour along the lines of Doug's Spectre-BHB
> changes queued on for-next/spectre-bhb-assume-vulnerable so that we
> assume vulnerable if we don't know better. To do otherwise will result
> in false assurances to userspace on derivative and third-party
> implementations.

Is the idea here that we'd assume any part with FEAT_CSV3 is vulnerable
to CVE-2024-7881 unless told otherwise by firmware / known good list of
implementations?

ARCH_WORKAROUND_4 assumes software has already detected an affected
implementation and doesn't distinguish between "not affected" and "not
mitigated". So I'd be concerned that we're gonna turn on KPTI for a load
of unrelated parts for something that hasn't (yet) been defined as a new
ecosystem bug.

> To be clear: I'm not at all against mitigating this problem and
> advertising the status of that mitigation. I *am* against quietly
> handling it like a CPU erratum whilst simultaneously telling userspace
> that meltdown is not a problem regardless of the mitigation state.

I like your idea of treating this as a broken CSV3 implementation
instead of an entirely new CPU bug, if only to avoid the 'assume the
worst' problem.

Either way KVM will need to implement the SMCCC call to the letter, even
if we wind up nuking CSV3.

Thanks,
Oliver

Re: [PATCH 0/4] arm64: mitigate CVE-2024-7881 in the absence of firmware mitigation

[Catalin Marinas]

On Mon, Mar 17, 2025 at 03:38:34PM -0700, Oliver Upton wrote:
> On Mon, Mar 17, 2025 at 09:26:12PM +0000, Will Deacon wrote:
> > On Fri, Mar 14, 2025 at 06:37:25PM +0000, Catalin Marinas wrote:
> > > On Tue, 28 Jan 2025 15:54:24 +0000, Mark Rutland wrote:
> > > > On some CPUs from Arm Ltd, it is possible for unprivileged code to cause
> > > > a hardware prefetcher to form an address using the contents of a memory
> > > > location which is accessible by privileged accesses in the active
> > > > translation regime, potentially leaking the contents of this memory
> > > > location via a side channel. This has been assigned CVE-2024-7881:
> > > > 
> > > >   https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-7881
> > > > 
> > > > [...]
> > > 
> > > Applied to arm64 (for-next/leaky-prefetcher), thanks!
> > > 
> > > There hasn't been much review (thanks Oliver for looking at the KVM
> > > bits) and there's some implied work that can go on top of this series.
> > > But the patches looked fine to me, so I queued them. Mark or others,
> > > please shout if you'd like them dropped, they are on a branch.
> > 
> > I'm really not comfortable with this series and would prefer to see it
> > dropped while we continue the discussion, especially as it's causing
> > minor conflicts with the KVM/arm64 tree in -next.
> 
> Catalin, unless you say otherwise, I'm going to assume this will be
> dropped in the interim.

Yes, I just dropped it.

-- 
Catalin