xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@arm.com>
To: xen-devel@lists.xenproject.org
Cc: olekstysh@gmail.com, oleksandr_tyshchenko@epam.com,
	Julien Grall <julien.grall@arm.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: [Xen-devel] [PATCH] xen/arm: p2m: Free the p2m entry after flushing the IOMMU TLBs
Date: Mon, 12 Aug 2019 21:27:35 +0100	[thread overview]
Message-ID: <20190812202735.23411-1-julien.grall@arm.com> (raw)

When freeing a p2m entry, all the sub-tree behind it will also be freed.
This may include intermediate page-tables or any l3 entry requiring to
drop a reference (e.g for foreign pages). As soon as pages are freed,
they may be re-used by Xen or another domain. Therefore it is necessary
to flush *all* the TLBs beforehand.

While CPU TLBs will be flushed before freeing the pages, this is not
the case for IOMMU TLBs. This can be solved by moving the IOMMU TLBs
flush earlier in the code.

This wasn't considered as a security issue as device passthrough on Arm
is not security supported.

Signed-off-by: Julien Grall <julien.grall@arm.com>

---

Cc: olekstysh@gmail.com
Cc: oleksandr_tyshchenko@epam.com

    I discovered it while looking at the code, so I don't have any
    reproducer of the issue. There is a small windows where page could
    be reallocated to Xen or another domain but still present in the
    IOMMU TLBs.

    This patch only address the case where the flush succeed. In the
    unlikely case where it does not succeed, then we will still free the
    pages. The IOMMU helper will crash domain, but the device may still
    not be quiescent. So there are a potentially issues do DMA on wrong
    things.

    At the moment, none of the Arm IOMMUs drivers (including the IPMMU
    one under review) are return an error here. Note that flush may
    still fail (see timeout), but is ignored. This is not great as it
    means a device may DMA into something that does not belong to the
    domain. So we probably want to return an error here.

    Even if an error is returned, there are still potential issues
    (see above). The fix is not entirely trivial, we would need to keep
    the page around until the a device is quiescent or the IOMMU is
    reset. This mostly likely means until the domain is fully destroyed.

    One of the solution would be to:
       1) Have a pool of memory for each domain p2m page-tables. So the
       domain can only touch itself
       2) Defer foreign mapping removal

    1) should also solve the case where the P2M is trying to shatter
    everything and therefore hog the memory. Note that today we don't
    free empty page-tables.

    2) I always felt trying to remove the foreign page reference in the
    p2m code was wrong. This is done because we currently allow the
    guest to remove any mapping. So we need to protect ourself against a
    rogue guest. We could try to restrict what the guest can do on the
    p2m.
---
 xen/arch/arm/p2m.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 3c8287a048..963cd1d600 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1048,14 +1048,6 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
         p2m->lowest_mapped_gfn = gfn_min(p2m->lowest_mapped_gfn, sgfn);
     }
 
-    /*
-     * Free the entry only if the original pte was valid and the base
-     * is different (to avoid freeing when permission is changed).
-     */
-    if ( p2m_is_valid(orig_pte) &&
-         !mfn_eq(lpae_get_mfn(*entry), lpae_get_mfn(orig_pte)) )
-        p2m_free_entry(p2m, orig_pte, level);
-
     if ( has_iommu_pt(p2m->domain) &&
          (lpae_is_valid(orig_pte) || lpae_is_valid(*entry)) )
     {
@@ -1072,6 +1064,14 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
     else
         rc = 0;
 
+    /*
+     * Free the entry only if the original pte was valid and the base
+     * is different (to avoid freeing when permission is changed).
+     */
+    if ( p2m_is_valid(orig_pte) &&
+         !mfn_eq(lpae_get_mfn(*entry), lpae_get_mfn(orig_pte)) )
+        p2m_free_entry(p2m, orig_pte, level);
+
 out:
     unmap_domain_page(table);
 
-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

             reply	other threads:[~2019-08-12 20:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-12 20:27 Julien Grall [this message]
2019-08-13  8:03 ` [Xen-devel] [PATCH] xen/arm: p2m: Free the p2m entry after flushing the IOMMU TLBs Andrew Cooper
2019-08-13  8:59   ` Julien Grall
2019-08-20 15:04 ` Oleksandr
2019-10-02  2:07 ` Stefano Stabellini
2019-10-02  5:07   ` Jürgen Groß

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=20190812202735.23411-1-julien.grall@arm.com \
    --to=julien.grall@arm.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=oleksandr_tyshchenko@epam.com \
    --cc=olekstysh@gmail.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /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).