lkml.org 
[lkml]   [2023]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH] KVM: x86: Track supported ARCH_CAPABILITIES in kvm_caps
    From
    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().

    \
     
     \ /
      Last update: 2023-05-22 18:48    [W:4.699 / U:0.096 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site