All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Le Tan <tamlokveer@gmail.com>,
	Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	wei.huang2@amd.com, qemu-devel@nongnu.org,
	Luiz Capitulino <lcapitulino@redhat.com>,
	Auger Eric <eric.auger@redhat.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Wei Yang <richardw.yang@linux.intel.com>,
	Igor Mammedov <imammedo@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	"Dr . David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [PATCH PROTOTYPE 3/6] vfio: Implement support for sparse RAM memory regions
Date: Wed, 18 Nov 2020 14:05:08 -0500	[thread overview]
Message-ID: <20201118190508.GD29639@xz-x1> (raw)
In-Reply-To: <1f1602db-748a-4e9d-dfde-950b573592fb@redhat.com>

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



  reply	other threads:[~2020-11-18 19:08 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-24 16:04 [PATCH PROTOTYPE 0/6] virtio-mem: vfio support David Hildenbrand
2020-09-24 16:04 ` [PATCH PROTOTYPE 1/6] memory: Introduce sparse RAM handler for memory regions David Hildenbrand
2020-10-20 19:24   ` Peter Xu
2020-10-20 20:13     ` David Hildenbrand
2020-09-24 16:04 ` [PATCH PROTOTYPE 2/6] virtio-mem: Impelement SparseRAMHandler interface David Hildenbrand
2020-09-24 16:04 ` [PATCH PROTOTYPE 3/6] vfio: Implement support for sparse RAM memory regions David Hildenbrand
2020-10-20 19:44   ` Peter Xu
2020-10-20 20:01     ` David Hildenbrand
2020-10-20 20:44       ` Peter Xu
2020-11-12 10:11         ` David Hildenbrand
2020-11-18 13:04         ` David Hildenbrand
2020-11-18 15:23           ` Peter Xu
2020-11-18 16:14             ` David Hildenbrand
2020-11-18 17:01               ` Peter Xu
2020-11-18 17:37                 ` David Hildenbrand
2020-11-18 19:05                   ` Peter Xu [this message]
2020-11-18 19:20                     ` David Hildenbrand
2020-09-24 16:04 ` [PATCH PROTOTYPE 4/6] memory: Extend ram_block_discard_(require|disable) by two discard types David Hildenbrand
2020-10-20 19:17   ` Peter Xu
2020-10-20 19:58     ` David Hildenbrand
2020-10-20 20:49       ` Peter Xu
2020-10-20 21:30         ` Peter Xu
2020-09-24 16:04 ` [PATCH PROTOTYPE 5/6] virtio-mem: Require only RAM_BLOCK_DISCARD_T_COORDINATED discards David Hildenbrand
2020-09-24 16:04 ` [PATCH PROTOTYPE 6/6] vfio: Disable only RAM_BLOCK_DISCARD_T_UNCOORDINATED discards David Hildenbrand
2020-09-24 19:30 ` [PATCH PROTOTYPE 0/6] virtio-mem: vfio support no-reply
2020-09-29 17:02 ` Dr. David Alan Gilbert
2020-09-29 17:05   ` David Hildenbrand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201118190508.GD29639@xz-x1 \
    --to=peterx@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=david@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=mst@redhat.com \
    --cc=pankaj.gupta.linux@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richardw.yang@linux.intel.com \
    --cc=tamlokveer@gmail.com \
    --cc=wei.huang2@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.