On 27.11.24 03:00, zhi zhang wrote:
On Tue, Nov 26, 2024 at 11:52 PM David Hildenbrand <da...@redhat.com
<mailto:da...@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
