On Wed, Nov 18, 2020 at 06:37:42PM +0100, David Hildenbrand wrote: > > > a) Unplugging plugged virtio-mem blocks while they are mapped via an > > > IOMMU > > > > > > 1. Guest: map memory location X located on a virtio-mem device inside a > > > plugged block into the IOMMU > > > -> QEMU IOMMU notifier: create vfio DMA mapping > > > -> VFIO pins memory of unplugged blocks (populating memory) > > > 2. Guest: Request to unplug memory location X via virtio-mem device > > > -> QEMU virtio-mem: discards the memory. > > > -> VFIO still has the memory pinned
[...] > > > b) Mapping unplugged virtio-mem blocks via an IOMMU > > > > > > 1. Guest: map memory location X located on a virtio-mem device inside an > > > unplugged block > > > -> QEMU IOMMU notifier: create vfio DMA mapping > > > -> VFIO pins memory of unplugged blocks (populating memory) [...] > Again, sane guests will never do that, for the very reason you mentioned > "the guest should know that this region of virtio-mem is not valid since > unplugged,". But a malicious guest could try doing that to cause trouble :) Oh I think I see your point now. :) And thanks for the write-up about how virtio-mem works. So it's about the malicious guests. I agree with you that we can try to limit above from happening, e.g. by teaching vfio_get_xlat_addr() to fail when it's going to map some unplugged range of virtio-mem device. Or... imho, we may not even need to worry too much on those misuses of virtio-mem? As long as the issue is self-contained within the buggy VM/process. E.g., the worst case of such a malicious guest is to fiddle around the maximum allowed memory size granted to the virtio-mem device to either have pages incorrectly pinned, or some strange IOVA mapped to unplugged pages within that range. As long as it won't affect other VMs and the host, and qemu won't crash with that, then it seems ok. -- Peter Xu
