Re: [PATCH] KVM: x86: Track supported ARCH_CAPABILITIES in kvm_caps

From: Dave Hansen
Date: Mon May 22 2023 - 10:24:54 EST


On 5/18/23 10:33, Sean Christopherson wrote:
>
> 2. I'm pretty sure conditioning mmio_stale_data_clear on kvm_arch_has_assigned_device()
> is a bug. AIUI, the vulnerability applies to _any_ MMIO accesses. Assigning
> a device is necessary to let the device DMA into the guest, but it's not
> necessary to let the guest access MMIO addresses, that's done purely via
> memslots.

Just to make sure we're all on the same page: KVM needs mitigations when
real, hardware MMIO is exposed to the guest. None of this has anything
to do with virtio or what guests _normally_ see as devices or MMIO. Right?

But direct device assignment does that "real hardware MMIO" for sure
because it's mapping parts of the PCI address space (which is all MMIO)
into the guest. That's what the kvm_arch_has_assigned_device() check
was going for.

But I think you're also saying that, in the end, memory gets exposed to
the guest by KVM userspace setting up a memslot. KVM userspace _could_
have mapped a piece of MMIO and could just pass that down to a guest
without kvm_arch_has_assigned_device() being involved. That makes the
kvm_arch_has_assigned_device() useless.

In other words, all guests with kvm_arch_has_assigned_device() need
mitigation. But there are potentially situations where the guest can
see real hardware MMIO and yet also be !kvm_arch_has_assigned_device().