[PATCH v2 0/4] KVM: arm64: Fix stale MTE tags reaching a guest

[Fuad Tabba]

Hi folks,

Changes since v1 [1]:
  - Added patch 4, mte_clear_folio_tags(). (Lorenzo)
  - Moved patch 3's sanitise_mte_tags() call into the
    kvm_pgtable_stage2_map() branch. (Lorenzo)
  - Patch 1 loops with folio_page() rather than reusing page, and its
    comment now matches patch 2's. (Lorenzo)
  - Collected Reviewed-by from Lorenzo on patches 1-3. (thanks!)

Three fixes for hugetlb and THP pages that reach an MTE guest without
their tags cleared, so the guest can read whatever tags the pages'
previous owners left.

The first clears the whole of a hugetlb folio before marking it tagged,
rather than only the pages being mapped. The second does the same when
KVM_ARM_MTE_COPY_TAGS copies tags into a page. The third sanitises when
a permission fault installs a THP block, and runs the VM_MTE_ALLOWED
check on permission faults too. A VMM that maps guest memory with
PROT_MTE isn't affected, as faulting that memory into its mapping clears
the tags first. QEMU and kvmtool map it without.

The fourth is a cleanup: it factors out the first two patches'
folio-clearing loop into mte_clear_folio_tags(), which mte_sync_tags()
now uses too.

I have a reproducer that reads the previous owner's tag from 511 of 512
pages in each case. With this series applied, it reads none.

Based on Linux 7.3-rc3 (fd73f4a665989; also applies to kvmarm/next
dd0bc00e3e920 with a three-way merge).

Cheers,
/fuad

[1] https://lore.kernel.org/all/20261019132103.3836646-1-fuad.tabba@xxxxxxxxx/

Fuad Tabba (4):
  KVM: arm64: Clear the whole hugetlb folio when sanitising MTE tags
  KVM: arm64: Clear the whole hugetlb folio when storing MTE tags
  KVM: arm64: Sanitise MTE tags when a permission fault installs a
    mapping
  arm64: mte: Add mte_clear_folio_tags()

 arch/arm64/include/asm/mte.h |  4 ++++
 arch/arm64/kernel/mte.c      | 15 ++++++++++-----
 arch/arm64/kvm/guest.c       | 11 +++++++----
 arch/arm64/kvm/mmu.c         | 13 ++++++-------
 4 files changed, 27 insertions(+), 16 deletions(-)


base-commit: fd73f4a6659897191fa0d40695fe370925dd3780
-- 
2.47.3