From: Jason Wang <jasowang@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Cindy Lu <lulu@redhat.com>,
mst@redhat.com, pbonzini@redhat.com, peterx@redhat.com,
david@redhat.com, f4bug@amsat.org, sgarzare@redhat.com,
qemu-devel@nongnu.org
Subject: Re: [PATCH v4 1/2] vfio: move the function vfio_get_xlat_addr() to memory.c
Date: Fri, 28 Oct 2022 10:40:45 +0800 [thread overview]
Message-ID: <CACGkMEthypOjZ1_YhK5nq7+qwZgnY7E9DMwcqnFP+0=eXuhvyw@mail.gmail.com> (raw)
In-Reply-To: <20221027203521.7ee26ec9.alex.williamson@redhat.com>
On Fri, Oct 28, 2022 at 10:35 AM Alex Williamson
<alex.williamson@redhat.com> wrote:
>
> On Fri, 28 Oct 2022 10:23:16 +0800
> Jason Wang <jasowang@redhat.com> wrote:
>
> > On Fri, Oct 28, 2022 at 10:08 AM Alex Williamson
> > <alex.williamson@redhat.com> wrote:
> > >
> > > On Fri, 28 Oct 2022 09:50:10 +0800
> > > Jason Wang <jasowang@redhat.com> wrote:
> > >
> > > > On Fri, Oct 28, 2022 at 5:11 AM Alex Williamson
> > > > <alex.williamson@redhat.com> wrote:
> > > > >
> > > > > On Thu, 27 Oct 2022 15:40:31 +0800
> > > > > Cindy Lu <lulu@redhat.com> wrote:
> > > > >
> > > > > > Move the function vfio_get_xlat_addr to softmmu/memory.c, and
> > > > > > change the name to memory_get_xlat_addr().So we can use this
> > > > > > function in other devices,such as vDPA device.
> > > > > >
> > > > > > Signed-off-by: Cindy Lu <lulu@redhat.com>
> > > > > > ---
> > > > > > hw/vfio/common.c | 92 ++-----------------------------------------
> > > > > > include/exec/memory.h | 4 ++
> > > > > > softmmu/memory.c | 84 +++++++++++++++++++++++++++++++++++++++
> > > > > > 3 files changed, 92 insertions(+), 88 deletions(-)
> > > > > >
> > > > > > diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> > > > > > index ace9562a9b..2b5a9f3d8d 100644
> > > > > > --- a/hw/vfio/common.c
> > > > > > +++ b/hw/vfio/common.c
> > > > > > @@ -574,92 +574,6 @@ static bool vfio_listener_skipped_section(MemoryRegionSection *section)
> > > > > > section->offset_within_address_space & (1ULL << 63);
> > > > > > }
> > > > > >
> > > > > > -/* Called with rcu_read_lock held. */
> > > > > > -static bool vfio_get_xlat_addr(IOMMUTLBEntry *iotlb, void **vaddr,
> > > > > > - ram_addr_t *ram_addr, bool *read_only)
> > > > > > -{
> > > > > > - MemoryRegion *mr;
> > > > > > - hwaddr xlat;
> > > > > > - hwaddr len = iotlb->addr_mask + 1;
> > > > > > - bool writable = iotlb->perm & IOMMU_WO;
> > > > > > -
> > > > > > - /*
> > > > > > - * The IOMMU TLB entry we have just covers translation through
> > > > > > - * this IOMMU to its immediate target. We need to translate
> > > > > > - * it the rest of the way through to memory.
> > > > > > - */
> > > > > > - mr = address_space_translate(&address_space_memory,
> > > > > > - iotlb->translated_addr,
> > > > > > - &xlat, &len, writable,
> > > > > > - MEMTXATTRS_UNSPECIFIED);
> > > > > > - if (!memory_region_is_ram(mr)) {
> > > > > > - error_report("iommu map to non memory area %"HWADDR_PRIx"",
> > > > > > - xlat);
> > > > > > - return false;
> > > > > > - } else if (memory_region_has_ram_discard_manager(mr)) {
> > > > > > - RamDiscardManager *rdm = memory_region_get_ram_discard_manager(mr);
> > > > > > - MemoryRegionSection tmp = {
> > > > > > - .mr = mr,
> > > > > > - .offset_within_region = xlat,
> > > > > > - .size = int128_make64(len),
> > > > > > - };
> > > > > > -
> > > > > > - /*
> > > > > > - * Malicious VMs can map memory into the IOMMU, which is expected
> > > > > > - * to remain discarded. vfio will pin all pages, populating memory.
> > > > > > - * Disallow that. vmstate priorities make sure any RamDiscardManager
> > > > > > - * were already restored before IOMMUs are restored.
> > > > > > - */
> > > > > > - if (!ram_discard_manager_is_populated(rdm, &tmp)) {
> > > > > > - error_report("iommu map to discarded memory (e.g., unplugged via"
> > > > > > - " virtio-mem): %"HWADDR_PRIx"",
> > > > > > - iotlb->translated_addr);
> > > > > > - return false;
> > > > > > - }
> > > > > > -
> > > > > > - /*
> > > > > > - * Malicious VMs might trigger discarding of IOMMU-mapped memory. The
> > > > > > - * pages will remain pinned inside vfio until unmapped, resulting in a
> > > > > > - * higher memory consumption than expected. If memory would get
> > > > > > - * populated again later, there would be an inconsistency between pages
> > > > > > - * pinned by vfio and pages seen by QEMU. This is the case until
> > > > > > - * unmapped from the IOMMU (e.g., during device reset).
> > > > > > - *
> > > > > > - * With malicious guests, we really only care about pinning more memory
> > > > > > - * than expected. RLIMIT_MEMLOCK set for the user/process can never be
> > > > > > - * exceeded and can be used to mitigate this problem.
> > > > > > - */
> > > > > > - warn_report_once("Using vfio with vIOMMUs and coordinated discarding of"
> > > > > > - " RAM (e.g., virtio-mem) works, however, malicious"
> > > > > > - " guests can trigger pinning of more memory than"
> > > > > > - " intended via an IOMMU. It's possible to mitigate "
> > > > > > - " by setting/adjusting RLIMIT_MEMLOCK.");
> > > > > > - }
> > > > > > -
> > > > > > - /*
> > > > > > - * Translation truncates length to the IOMMU page size,
> > > > > > - * check that it did not truncate too much.
> > > > > > - */
> > > > > > - if (len & iotlb->addr_mask) {
> > > > > > - error_report("iommu has granularity incompatible with target AS");
> > > > > > - return false;
> > > > > > - }
> > > > > > -
> > > > > > - if (vaddr) {
> > > > > > - *vaddr = memory_region_get_ram_ptr(mr) + xlat;
> > > > > > - }
> > > > > > -
> > > > > > - if (ram_addr) {
> > > > > > - *ram_addr = memory_region_get_ram_addr(mr) + xlat;
> > > > > > - }
> > > > > > -
> > > > > > - if (read_only) {
> > > > > > - *read_only = !writable || mr->readonly;
> > > > > > - }
> > > > > > -
> > > > > > - return true;
> > > > > > -}
> > > > > > -
> > > > > > static void vfio_iommu_map_notify(IOMMUNotifier *n, IOMMUTLBEntry *iotlb)
> > > > > > {
> > > > > > VFIOGuestIOMMU *giommu = container_of(n, VFIOGuestIOMMU, n);
> > > > > > @@ -682,7 +596,8 @@ static void vfio_iommu_map_notify(IOMMUNotifier *n, IOMMUTLBEntry *iotlb)
> > > > > > if ((iotlb->perm & IOMMU_RW) != IOMMU_NONE) {
> > > > > > bool read_only;
> > > > > >
> > > > > > - if (!vfio_get_xlat_addr(iotlb, &vaddr, NULL, &read_only)) {
> > > > > > + if (!memory_get_xlat_addr(iotlb, &vaddr, NULL, &read_only,
> > > > > > + &address_space_memory)) {
> > > > > > goto out;
> > > > > > }
> > > > > > /*
> > > > > > @@ -1359,7 +1274,8 @@ static void vfio_iommu_map_dirty_notify(IOMMUNotifier *n, IOMMUTLBEntry *iotlb)
> > > > > > }
> > > > > >
> > > > > > rcu_read_lock();
> > > > > > - if (vfio_get_xlat_addr(iotlb, NULL, &translated_addr, NULL)) {
> > > > > > + if (memory_get_xlat_addr(iotlb, NULL, &translated_addr, NULL,
> > > > > > + &address_space_memory)) {
> > > > > > int ret;
> > > > > >
> > > > > > ret = vfio_get_dirty_bitmap(container, iova, iotlb->addr_mask + 1,
> > > > > > diff --git a/include/exec/memory.h b/include/exec/memory.h
> > > > > > index bfb1de8eea..282de1d5ad 100644
> > > > > > --- a/include/exec/memory.h
> > > > > > +++ b/include/exec/memory.h
> > > > > > @@ -713,6 +713,10 @@ void ram_discard_manager_register_listener(RamDiscardManager *rdm,
> > > > > > void ram_discard_manager_unregister_listener(RamDiscardManager *rdm,
> > > > > > RamDiscardListener *rdl);
> > > > > >
> > > > > > +bool memory_get_xlat_addr(IOMMUTLBEntry *iotlb, void **vaddr,
> > > > > > + ram_addr_t *ram_addr, bool *read_only,
> > > > > > + AddressSpace *as);
> > > > > > +
> > > > > > typedef struct CoalescedMemoryRange CoalescedMemoryRange;
> > > > > > typedef struct MemoryRegionIoeventfd MemoryRegionIoeventfd;
> > > > > >
> > > > > > diff --git a/softmmu/memory.c b/softmmu/memory.c
> > > > > > index 7ba2048836..8586863ffa 100644
> > > > > > --- a/softmmu/memory.c
> > > > > > +++ b/softmmu/memory.c
> > > > > > @@ -2121,6 +2121,90 @@ void ram_discard_manager_unregister_listener(RamDiscardManager *rdm,
> > > > > > rdmc->unregister_listener(rdm, rdl);
> > > > > > }
> > > > > >
> > > > > > +/* Called with rcu_read_lock held. */
> > > > > > +bool memory_get_xlat_addr(IOMMUTLBEntry *iotlb, void **vaddr,
> > > > > > + ram_addr_t *ram_addr, bool *read_only,
> > > > > > + AddressSpace *as)
> > > > > > +{
> > > > > > + MemoryRegion *mr;
> > > > > > + hwaddr xlat;
> > > > > > + hwaddr len = iotlb->addr_mask + 1;
> > > > > > + bool writable = iotlb->perm & IOMMU_WO;
> > > > > > +
> > > > > > + /*
> > > > > > + * The IOMMU TLB entry we have just covers translation through
> > > > > > + * this IOMMU to its immediate target. We need to translate
> > > > > > + * it the rest of the way through to memory.
> > > > > > + */
> > > > > > + mr = address_space_translate(as, iotlb->translated_addr, &xlat, &len,
> > > > > > + writable, MEMTXATTRS_UNSPECIFIED);
> > > > > > + if (!memory_region_is_ram(mr)) {
> > > > > > + error_report("iommu map to non memory area %" HWADDR_PRIx "", xlat);
> > > > > > + return false;
> > > > > > + } else if (memory_region_has_ram_discard_manager(mr)) {
> > > > > > + RamDiscardManager *rdm = memory_region_get_ram_discard_manager(mr);
> > > > > > + MemoryRegionSection tmp = {
> > > > > > + .mr = mr,
> > > > > > + .offset_within_region = xlat,
> > > > > > + .size = int128_make64(len),
> > > > > > + };
> > > > > > +
> > > > > > + /*
> > > > > > + * Malicious VMs can map memory into the IOMMU, which is expected
> > > > > > + * to remain discarded. device will pin all pages, populating memory.
> > > > > > + * Disallow that. vmstate priorities make sure any RamDiscardManager
> > > > > > + * were already restored before IOMMUs are restored.
> > > > > > + */
> > > > > > + if (!ram_discard_manager_is_populated(rdm, &tmp)) {
> > > > > > + error_report("iommu map to discarded memory (e.g., unplugged via"
> > > > > > + " virtio-mem): %" HWADDR_PRIx "",
> > > > > > + iotlb->translated_addr);
> > > > > > + return false;
> > > > > > + }
> > > > > > +
> > > > > > + /*
> > > > > > + * Malicious VMs might trigger discarding of IOMMU-mapped memory. The
> > > > > > + * pages will remain pinned inside device until unmapped, resulting in a
> > > > > > + * higher memory consumption than expected. If memory would get
> > > > > > + * populated again later, there would be an inconsistency between pages
> > > > > > + * pinned by device and pages seen by QEMU. This is the case until
> > > > > > + * unmapped from the IOMMU (e.g., during device reset).
> > > > > > + *
> > > > > > + * With malicious guests, we really only care about pinning more memory
> > > > > > + * than expected. RLIMIT_MEMLOCK set for the user/process can never be
> > > > > > + * exceeded and can be used to mitigate this problem.
> > > > > > + */
> > > > > > + warn_report_once("Using device with vIOMMUs and coordinated discarding"
> > > > > > + " of RAM (e.g., virtio-mem) works, however, malicious"
> > > > > > + " guests can trigger pinning of more memory than"
> > > > > > + " intended via an IOMMU. It's possible to mitigate "
> > > > > > + " by setting/adjusting RLIMIT_MEMLOCK.");
> > > > >
> > > > > Is this really fit to be in shared code? Simply replacing "vfio" with
> > > > > "device" for comments and warnings that are really of concern for a
> > > > > specific use case doesn't look much better to me.
> > > > >
> > > > > I think translating an unpopulated address, as in the previous test
> > > > > above, is generally invalid, but the comment is certainly trying to
> > > > > frame the severity of this error relative to a specific use case.
> > > > >
> > > > > Here we're generating an unconditional warning, assuming that this code
> > > > > path has been triggered by device code, for the condition of simply
> > > > > asking for a translation to a MemoryRegion under discard manager
> > > > > control? Again, isn't that an action that has implications for a
> > > > > specific use case of a device that supports pinning host memory?
> > > >
> > > >
> > > > Or can we rename the function to memory_get_xlat_addr_no_discard()?
> > > > This looks more general and fit for the caller that doesn't want to
> > > > map region that has a discard manager.
> > >
> > > Is a guest restricted from mapping virtio-mem regions to a device?
> >
> > For the region that is not populated, it should be restricted. If this
> > is wrong, we need a separate fix.
> >
> > > AFAIK, this is something that a guest can do and we can't restrict them
> > > from doing it, it's just that it opens some potential for malicious
> > > activity that we rely on things like locked memory limits to keep from
> > > getting out of hand. Thanks,
> >
> > So it's the fault of the name, it could be
> > memory_get_xlat_addr_no_unpopulated_discard().
>
> Unpopulated discard has no translation, it's invalid. That's the
> previous test above where we return false. The comment there is a bit
> vfio specific, but I think the behavior is universal. That doesn't
> resolve this warn_report_once for simply trying to translate something
> backed by virtio-mem though. Thanks,
Ok, fine, let's add an optional arg then.
Thanks
>
> Alex
>
> > Or as I replied, stick to what you've suggested.
> >
> > Thanks
> >
> > >
> > > Alex
> > >
> > > > > Should the shared code be generating this warning, or could an optional
> > > > > pointer arg be updated to indicate a translation to discard manager
> > > > > controlled memory and this comment and warning should remain in the
> > > > > caller? Thanks,
> > > >
> > > > I think this should also work.
> > > >
> > > > Thanks
> > > >
> > > > >
> > > > > Alex
> > > > >
> > > > > > + }
> > > > > > +
> > > > > > + /*
> > > > > > + * Translation truncates length to the IOMMU page size,
> > > > > > + * check that it did not truncate too much.
> > > > > > + */
> > > > > > + if (len & iotlb->addr_mask) {
> > > > > > + error_report("iommu has granularity incompatible with target AS");
> > > > > > + return false;
> > > > > > + }
> > > > > > +
> > > > > > + if (vaddr) {
> > > > > > + *vaddr = memory_region_get_ram_ptr(mr) + xlat;
> > > > > > + }
> > > > > > +
> > > > > > + if (ram_addr) {
> > > > > > + *ram_addr = memory_region_get_ram_addr(mr) + xlat;
> > > > > > + }
> > > > > > +
> > > > > > + if (read_only) {
> > > > > > + *read_only = !writable || mr->readonly;
> > > > > > + }
> > > > > > +
> > > > > > + return true;
> > > > > > +}
> > > > > > +
> > > > > > void memory_region_set_log(MemoryRegion *mr, bool log, unsigned client)
> > > > > > {
> > > > > > uint8_t mask = 1 << client;
> > > > >
> > > >
> > >
> >
>
next prev parent reply other threads:[~2022-10-28 2:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-27 7:40 [PATCH v4 0/2] vhost-vdpa: add support for vIOMMU Cindy Lu
2022-10-27 7:40 ` [PATCH v4 1/2] vfio: move the function vfio_get_xlat_addr() to memory.c Cindy Lu
2022-10-27 8:11 ` Jason Wang
2022-10-27 15:30 ` Peter Xu
2022-10-27 21:11 ` Alex Williamson
2022-10-28 1:50 ` Jason Wang
2022-10-28 2:08 ` Alex Williamson
2022-10-28 2:23 ` Jason Wang
2022-10-28 2:35 ` Alex Williamson
2022-10-28 2:40 ` Jason Wang [this message]
2022-10-27 7:40 ` [PATCH v4 2/2] vhost-vdpa: add support for vIOMMU Cindy Lu
2022-10-27 8:10 ` Jason Wang
2022-10-29 7:57 ` [PATCH v4 0/2] " Michael S. Tsirkin
2022-10-29 7:58 ` Cindy Lu
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='CACGkMEthypOjZ1_YhK5nq7+qwZgnY7E9DMwcqnFP+0=eXuhvyw@mail.gmail.com' \
--to=jasowang@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=david@redhat.com \
--cc=f4bug@amsat.org \
--cc=lulu@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=sgarzare@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).