> 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 Wed, Nov 27, 2024 at 5:37 PM David Hildenbrand <[email protected]> wrote: > On 27.11.24 03:00, zhi zhang wrote: > > > > > > On Tue, Nov 26, 2024 at 11:52 PM David Hildenbrand <[email protected] > > <mailto:[email protected]>> 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 > >
