Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] KVM: arm64: Reject guest_memfd memslots when the VM has MTE
@ 2026-07-14 11:07 Alexandru Elisei
  2026-07-14 11:44 ` Fuad Tabba
  0 siblings, 1 reply; 4+ messages in thread
From: Alexandru Elisei @ 2026-07-14 11:07 UTC (permalink / raw)
  To: maz, oupton, joey.gouly, seiden, suzuki.poulose, yuzenghui,
	linux-arm-kernel, kvmarm, catalin.marinas, will
  Cc: steven.price, fuad.tabba

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 explicitely
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@arm.com>
---

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;
 
 	hva = new->userspace_addr;

base-commit: a13c140cc289c0b7b3770bce5b3ad42ab35074aa
-- 
2.55.0



^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] KVM: arm64: Reject guest_memfd memslots when the VM has MTE
  2026-07-14 11:07 [PATCH] KVM: arm64: Reject guest_memfd memslots when the VM has MTE Alexandru Elisei
@ 2026-07-14 11:44 ` Fuad Tabba
  2026-07-14 13:15   ` Alexandru Elisei
  0 siblings, 1 reply; 4+ messages in thread
From: Fuad Tabba @ 2026-07-14 11:44 UTC (permalink / raw)
  To: Alexandru Elisei
  Cc: maz, oupton, joey.gouly, seiden, suzuki.poulose, yuzenghui,
	linux-arm-kernel, kvmarm, catalin.marinas, will, steven.price

Hi Alex,

On Tue, 14 Jul 2026 at 12:08, Alexandru Elisei <alexandru.elisei@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@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
>


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] KVM: arm64: Reject guest_memfd memslots when the VM has MTE
  2026-07-14 11:44 ` Fuad Tabba
@ 2026-07-14 13:15   ` Alexandru Elisei
  2026-07-14 14:13     ` Fuad Tabba
  0 siblings, 1 reply; 4+ messages in thread
From: Alexandru Elisei @ 2026-07-14 13:15 UTC (permalink / raw)
  To: Fuad Tabba
  Cc: maz, oupton, joey.gouly, seiden, suzuki.poulose, yuzenghui,
	linux-arm-kernel, kvmarm, catalin.marinas, will, steven.price

Hi Fuad,

On Tue, Jul 14, 2026 at 12:44:57PM +0100, Fuad Tabba wrote:
> Hi Alex,
> 
> On Tue, 14 Jul 2026 at 12:08, Alexandru Elisei <alexandru.elisei@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/

I think that's what I wrote :)

> 
> > 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@arm.com>
> 
> Is this worth a Fixes: tag?

Fixes: 32e200bd6e44 ("KVM: arm64: Enable support for guest_memfd backed memory")

?

> 
> > ---
> 
> 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 :)

Indentation worked, thanks.

> 
> >
> > 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;
> 

Sure.

> 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)
> 

Yes, that's a good point.

> 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.

I can iterate through all the memslots and check that none are backed by a
guest_memfd file when userspace enables the MTE capability.

Will wait for a day or two to send v2.

Thanks,
Alex


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] KVM: arm64: Reject guest_memfd memslots when the VM has MTE
  2026-07-14 13:15   ` Alexandru Elisei
@ 2026-07-14 14:13     ` Fuad Tabba
  0 siblings, 0 replies; 4+ messages in thread
From: Fuad Tabba @ 2026-07-14 14:13 UTC (permalink / raw)
  To: Alexandru Elisei
  Cc: maz, oupton, joey.gouly, seiden, suzuki.poulose, yuzenghui,
	linux-arm-kernel, kvmarm, catalin.marinas, will, steven.price

On Tue, 14 Jul 2026 at 14:15, Alexandru Elisei <alexandru.elisei@arm.com> wrote:
>
> Hi Fuad,
>
> On Tue, Jul 14, 2026 at 12:44:57PM +0100, Fuad Tabba wrote:
> > Hi Alex,
> >
> > On Tue, 14 Jul 2026 at 12:08, Alexandru Elisei <alexandru.elisei@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/
>
> I think that's what I wrote :)

I fixed the quoted text (pressing enter right after the word)! :) The
original msg says `explicitely`

It's a nit anyway.

> >
> > > 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@arm.com>
> >
> > Is this worth a Fixes: tag?
>
> Fixes: 32e200bd6e44 ("KVM: arm64: Enable support for guest_memfd backed memory")
> ?

Yes, the author of that patch should have known better...

<snip>

> I can iterate through all the memslots and check that none are backed by a
> guest_memfd file when userspace enables the MTE capability.

Sgtm.

Cheers,
/fuad

> Will wait for a day or two to send v2.
>
> Thanks,
> Alex


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2026-07-14 14:14 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-07-14 11:07 [PATCH] KVM: arm64: Reject guest_memfd memslots when the VM has MTE Alexandru Elisei
2026-07-14 11:44 ` Fuad Tabba
2026-07-14 13:15   ` Alexandru Elisei
2026-07-14 14:13     ` Fuad Tabba

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox