> That doesn't explain the full story about MIGRATE_UNMOVABLE. I assume
> one precondition is missing in your explanation.
I have double-checked the source code. My initial description of the
process seems somewhat imprecise. vIOMMU does not convert pages to
UNMOVABLE during pinning, it is that pinning causes page faults, and the
fault handler allocates UNMOVABLE pages. (vaddr_get_pfns() calls
__gup_longterm_locked(), who then calls memalloc_pin_save(), and it
implicitly removes the __GFP_MOVABLE flag.)
Therefore, there is no requirement of ZONE_MOVABLE and MIGRATE_CMA.
Best regards,
Wei Chen
On 27.11.24 03:00, zhi zhang wrote:
>
>
> On Tue, Nov 26, 2024 at 11:52 PM David Hildenbrand <david@redhat.com
> <mailto:david@redhat.com>> wrote:
>
> On 26.11.24 16:31, Wei Chen wrote:
> > > How can you be sure (IOW trigger) that the system will store
> > > "important data" like EPTs?
> >
> > We cannot, but we have designed the attack (see below) to improve the
> > possibility.
> >
> > > So is one magic bit really that for your experiments, one needs a
> > > viommu?
> >
> > Admittedly the way we accomplish a VM escape is a bit arcane.
>
> That's what I imagined :)
>
> >
> > We require device passthrough because it pins the VM's memory
> down and
> > converts them to MIGRATE_UNMOVABLE.
>
> Interesting, that's news to me. Can you share where GUP in the kernel
> would do that?
>
>
> In /drivers/vfio/vfio_iommu_type1.c, there is a function called
> vfio_iommu_type1_pin_pages where VM's memory is pinned down.
That doesn't explain the full story about MIGRATE_UNMOVABLE. I assume
one precondition is missing in your explanation.
VFIO will call pin_user_pages_remote(FOLL_LONGTERM). Two cases:
a) Memory is already allocated (which would mostly be MIGRATE_MOVABLE,
because it's ordinary user memory). We'll simply longterm pin the memory
without changing the migratetype.
b) Memory is not allocated yet. We'll call
faultin_page()->handle_mm_fault(). There is no FOLL_LONGTERM
special-casing, so you'll mostly get MIGRATE_MOVABLE.
Now, there is one corner case: we disallow longterm pinning on
ZONE_MOVABLE and MIGRATE_CMA. In case our user space allocation ended up
on there, check_and_migrate_movable_pages() would detect that the memory
resides on ZONE_MOVABLE or MIGRATE_CMA, and allocate a destination page
in migrate_longterm_unpinnable_folios() using "GFP_USER | __GFP_NOWARN".
So I assume one precondition is that your hypervisor has at least some
ZONE_MOVABLE or CMA memory? Otherwise I don't see how you would reliably
get MIGRATE_UNMOVABLE.
>
>
> > Hotplugged memory will also be
> > converted to MIGRATE_UNMOVABLE.
>
> But that's in the VM? Because we don't hotplug memory in the hypervisor.
>
>
> Yes, the virtio-mem driver in the VM is modified to actively release
> memory vulnerable to Rowhammer.
I think I now understand that statement: Memory to-be-hotplugged to the
VM will be migrated to MIGRATE_UNMOVABLE during longterm pinning, if it
resides on ZONE_MOVABLE or MIGRATE_CMA.
> For more details, would you be interested in reading our paper? It was
> recently submitted to ASPLOS for publication and we are happy to share
> it with you.
Yes, absolutely! Please send a private mail :)
--
Cheers,
David / dhildenb