[PATCH v4 0/4] arm64: Work around C1-Pro erratum 4193714 (CVE-2026-0995)

[Catalin Marinas <catalin.marinas@arm.com>]

Here's version 4 of the workaround for C1-Pro erratum 4193714. Version 3
was posted here:

https://lore.kernel.org/r/20260323162408.4163113-1-catalin.marinas@arm.com

The most significant change since v3 was the drop of the global
sme_dvmsync_cpus mask in favour of mm_cpumask(). Sashiko reported a
potential DoS if a malicious app does an madvise(MADV_PAGEOUT)
continuously. This would trigger a flood of IPIs to unrelated apps that
run at EL0 with SME on. We knew about this and deemed it low risk but I
thought I'd do some testing. On a Raspberry Pi 4 (no SME but hacked the
kernel to assume workaround always on) I can get about 30% drop in the
victim throughput due to the IPIs.

Since using mm_cpumask() to track which threads of an app run in
user-space with SME enabled, we can drop the MMCF_SME_DVMSYNC flag as
well. One downside is that arch_tlbbatch_add_pending() now needs a DSB
before checking the mm_cpumask() if the workaround is enabled. The
actual IPI is still batched. On hardware where this erratum is present
(small number of CPUs), I don't expect this to be noticeable.

Other changes since v3:

- Included acks from Mark Rutland but dropped it for the forth patch as
  it was heavily reworked.

- Dropped the KVM workaround due to conflicts with next. I'll rebase
  this patch it after -rc1. I also dropped the KVM and SMCCC people from
  cc until the KVM part will be posted.

- Added a raw_spin_lock() around the sme_enable_dvmsync() function and
  cpumask allocation. This function is called simultaneously on multiple
  CPUs via stop_machine(). In practice, CONFIG_CPUMASK_OFFSTACK is
  likely off on such hardware and no allocation needed.

I'll push the patches provisionally to for-next/c1-pro-erratum-4193714
for some exposure in -next. It doesn't necessarily mean they'll go
upstream for 7.1-rc1.

Erratum description:

Arm C1-Pro prior to r1p3 has an erratum (4193714) where a TLBI+DSB
sequence might fail to ensure the completion of all outstanding SME
(Scalable Matrix Extension) memory accesses. The DVMSync message is
acknowledged before the SME accesses have fully completed, potentially
allowing pages to be reused before all in-flight accesses are done.

The workaround consists of executing a DSB locally (via IPI)
on all affected CPUs running with SME enabled, after the TLB
invalidation. This ensures the SME accesses have completed before the
IPI is acknowledged.

This has been assigned CVE-2026-0995:

https://developer.arm.com/documentation/111823/latest/

Catalin Marinas (4):
  arm64: tlb: Introduce __tlbi_sync_s1ish_{kernel,batch}() for TLB
    maintenance
  arm64: tlb: Pass the corresponding mm to __tlbi_sync_s1ish()
  arm64: cputype: Add C1-Pro definitions
  arm64: errata: Work around early CME DVMSync acknowledgement

 Documentation/arch/arm64/silicon-errata.rst |  2 +
 arch/arm64/Kconfig                          | 12 +++
 arch/arm64/include/asm/cpucaps.h            |  2 +
 arch/arm64/include/asm/cputype.h            |  2 +
 arch/arm64/include/asm/fpsimd.h             | 21 +++++
 arch/arm64/include/asm/tlbbatch.h           | 10 ++-
 arch/arm64/include/asm/tlbflush.h           | 96 +++++++++++++++++++--
 arch/arm64/kernel/cpu_errata.c              | 30 +++++++
 arch/arm64/kernel/entry-common.c            |  3 +
 arch/arm64/kernel/fpsimd.c                  | 90 +++++++++++++++++++
 arch/arm64/kernel/process.c                 | 37 ++++++++
 arch/arm64/kernel/sys_compat.c              |  2 +-
 arch/arm64/tools/cpucaps                    |  1 +
 13 files changed, 297 insertions(+), 11 deletions(-)