[PATCH] KVM: arm64: Reject guest_memfd memslots when the VM has MTE

[Fuad Tabba]

Hi Alex,

On Tue, 14 Jul 2026 at 12:08, Alexandru Elisei <alexandru.elisei at arm.com> wrote:
>
> The user cannot use MTE on VMAs created by mapping a guest_memfd file,
> as arch_calc_vm_flag_bits() does not set VM_MTE_ALLOWED.
>
> When creating a guest_memfd backed memslot,
> kvm_arch_prepare_memory_region() rejects the memslot if MTE is enabled for
> the VM and if guest_memfd has been mapped in a VMA that intersects the
> memslot.
>
> However, the documentation for KVM_SET_USER_MEMORY_REGION2 explicitly

nit: s/explicitely/explicitly/

> states that the only condition for userspace_addr is for it to be a legal
> userspace address, but the mapping is not required to be valid nor
> populated at memslot creation.
>
> If userspace sets userspace_addr to an address that hasn't been mapped, or
> if userspace_addr belongs to a VMA that isn't backed by the guest_memfd
> file, or if the VMA doesn't intersect the memslot, memslot creation is
> successful and KVM ends up with a VM with MTE and guest_memfd-backed
> memslots.
>
> Forbid guest_memfd memslots unconditionally when the VM has MTE to prevent
> this from happening.
>
> Signed-off-by: Alexandru Elisei <alexandru.elisei at arm.com>

Is this worth a Fixes: tag?

> ---

git am chokes here: this kvmtool snippet between '---' and the real
diff parses as a stray patch fragment ("patch fragment without
header"). Worth indenting it or moving it below a scissors line ("--
>8 --") so the patch applies, though didn't test to see if this
actually works :)

>
> Tested by using Fuad's patches to add guest_memfd support for kvmtool at [1],
> with the following changes to arm64/kvm.c:
>
> @@ -125,10 +125,12 @@ static void kvm__arch_enable_mte(struct kvm *kvm)
>                 return;
>         }
>
> +       /*
>         if (kvm->cfg.arch.guest_memfd) {
>                 pr_debug("MTE is incompatible with guest_memfd");
>                 return;
>         }
> +       */
>
>         if (kvm->cfg.arch.mte_disabled) {
>                 pr_debug("MTE disabled by user");
>
> and kvm.c:
>
> @@ -332,8 +332,15 @@ int kvm__register_mem(struct kvm *kvm, u64 guest_phys, u64 size,
>                                 .guest_memfd_offset     = guest_memfd_offset,
>                         };
>
> +                       if (munmap(userspace_addr, size) < 0)
> +                               die_perror("munmap hack");
> +
>                         ret = ioctl(kvm->vm_fd, KVM_SET_USER_MEMORY_REGION2,
>                                     &mem2);
> +
> +                       if (mmap(userspace_addr, size, PROT_RW, MAP_SHARED | MAP_FIXED,
> +                           guest_memfd, guest_memfd_offset) == MAP_FAILED)
> +                               die_perror("mmap hack");
>                 } else {
>                         struct kvm_userspace_memory_region mem = {
>                                 .slot                   = slot,
>
> (not pasting the full diff because last time I did, git got confused and
> considered the snippet part of the actual patch).
>
> Without this patch, I was able to create a VM with MTE and guest_memfd
> backed ram (the guest reported MTE as enabled, but I didn't test that it
> actually worked).
>
> With this patch, creating a VM with MTE is rejected.
>
> [1] https://lore.kernel.org/kvmarm/20260712142536.1391557-1-fuad.tabba@linux.dev/
>
>  arch/arm64/kvm/mmu.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 6c941aaa10c6..30c2ea235fa5 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -2648,8 +2648,11 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
>         /*
>          * Only support guest_memfd backed memslots with mappable memory, since
>          * there aren't any CoCo VMs that support only private memory on arm64.
> +        *
> +        * MTE is also not supported with guest_memfd.
>          */
> -       if (kvm_slot_has_gmem(new) && !kvm_memslot_is_gmem_only(new))
> +       if (kvm_slot_has_gmem(new) &&
> +           (kvm_has_mte(kvm) || !kvm_memslot_is_gmem_only(new)))
>                 return -EINVAL;

This folds two unrelated rejections into one condition. I'd split them
so each carries its own comment:

        /* guest_memfd is incompatible with MTE. */
        if (kvm_slot_has_gmem(new) && kvm_has_mte(kvm))
            return -EINVAL;

        /*
         * Only support guest_memfd backed memslots with mappable memory,
         * since there aren't any CoCo VMs that support only private memory
         * on arm64.
         */
        if (kvm_slot_has_gmem(new) && !kvm_memslot_is_gmem_only(new))
            return -EINVAL;

More importantly, this only closes one direction.
prepare_memory_region() runs on memslot changes, but KVM_CAP_ARM_MTE
gates only on !kvm->created_vcpus and never looks at memslots, so the
reverse order still gets you there:

      1. KVM_SET_USER_MEMORY_REGION2 with a gmem slot   (no MTE yet -> ok)
      2. KVM_ENABLE_CAP(KVM_CAP_ARM_MTE) (no vCPUs -> ok)

Since the justification is that userspace can do unexpected things,
the enable-MTE path wants the symmetric check too (reject if a gmem
memslot already exists), or enforce the invariant at one choke point.

Cheers,
/fuad

>
>         hva = new->userspace_addr;
>
> base-commit: a13c140cc289c0b7b3770bce5b3ad42ab35074aa
> --
> 2.55.0
>