On 07.04.21 17:14, Catalin Marinas wrote:
On Wed, Apr 07, 2021 at 11:20:18AM +0100, Steven Price wrote:
On 31/03/2021 19:43, Catalin Marinas wrote:
When a slot is added by the VMM, if it asked for MTE in guest (I guess
that's an opt-in by the VMM, haven't checked the other patches), can we
reject it if it's is going to be mapped as Normal Cacheable but it is a
ZONE_DEVICE (i.e. !kvm_is_device_pfn() + one of David's suggestions to
check for ZONE_DEVICE)? This way we don't need to do more expensive
checks in set_pte_at().
The problem is that KVM allows the VMM to change the memory backing a slot
while the guest is running. This is obviously useful for the likes of
migration, but ultimately means that even if you were to do checks at the
time of slot creation, you would need to repeat the checks at set_pte_at()
time to ensure a mischievous VMM didn't swap the page for a problematic one.
Does changing the slot require some KVM API call? Can we intercept it
and do the checks there?
User space can simply mmap(MAP_FIXED) the user space area registered in
a KVM memory slot. You cannot really intercept that. You can only check
in the KVM MMU code at fault time that the VMA which you hold in your
hands is still in a proper state. The KVM MMU is synchronous, which
means that updates to the VMA layout are reflected in the KVM MMU page
tables -- e.g., via mmu notifier calls.
E.g., in s390x code we cannot handle VMAs with gigantic pages. We check
that when faulting (creating the links in the page table) via __gmap_link().
You could either check the page itself (ZONE_DEVICE) or might even be
able to check via the VMA/file.
--
Thanks,
David / dhildenb
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
