All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@citrix.com>
Subject: [Xen-devel] [PATCH v3 3/3] gnttab: don't expose host physical address without need
Date: Mon, 25 Nov 2019 10:59:28 +0100	[thread overview]
Message-ID: <1dcb0914-bdbb-6ffa-572b-c91b0ecdc5b3@suse.com> (raw)
In-Reply-To: <62a3d98f-8173-1b13-f20e-9bd000f0923f@suse.com>

Translated domains shouldn't see host physical addresses. While the
address is also not supposed to be handed back even to non-translated
domains when GNTMAP_device_map is not set (as explicitly stated by a
comment in the public header), PV kernels (Linux at least) assume the
field to get populated nevertheless. (Similarly mapkind() should check
only GNTMAP_device_map.)

Along these lines split the paging mode related check near the top of
map_grant_ref() to handle the "external" and "translated" cases
separately (GNTMAP_device_map use getting tied to being non-translated
rather than non-external), and make the assignment of ->dev_bus_addr
conditional upon the guest being a non-translated one.

Still along these lines in the unmapping case there's no point checking
->dev_bus_addr when GNTMAP_device_map isn't set (and hence the field
isn't going to be consumed).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v3: New.

--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -938,21 +938,29 @@ map_grant_ref(
     }
 
     if ( unlikely(paging_mode_external(ld) &&
-                  (op->flags & (GNTMAP_device_map|GNTMAP_application_map|
-                            GNTMAP_contains_pte))) )
+                  (op->flags & (GNTMAP_application_map|GNTMAP_contains_pte))) )
     {
-        gdprintk(XENLOG_INFO, "No device mapping in HVM domain\n");
+        gdprintk(XENLOG_INFO, "No application mapping in HVM domain\n");
         op->status = GNTST_general_error;
         return;
     }
 
-    if ( paging_mode_translate(ld) && (op->flags & GNTMAP_host_map) &&
-         (rc = notify_gfn(ld, gaddr_to_gfn(op->host_addr))) )
+    if ( paging_mode_translate(ld) )
     {
-        gdprintk(XENLOG_INFO, "notify(%"PRI_gfn") -> %d\n",
-                 gfn_x(gaddr_to_gfn(op->host_addr)), rc);
-        op->status = GNTST_general_error;
-        return;
+        if ( unlikely((op->flags & GNTMAP_device_map)) )
+        {
+            gdprintk(XENLOG_INFO, "No device mapping in translated domain\n");
+            op->status = GNTST_general_error;
+            return;
+        }
+
+        if ( unlikely(rc = notify_gfn(ld, gaddr_to_gfn(op->host_addr))) )
+        {
+            gdprintk(XENLOG_INFO, "notify(%"PRI_gfn") -> %d\n",
+                     gfn_x(gaddr_to_gfn(op->host_addr)), rc);
+            op->status = GNTST_general_error;
+            return;
+        }
         BUILD_BUG_ON(GNTST_okay);
     }
 
@@ -1201,7 +1209,8 @@ map_grant_ref(
     if ( need_iommu )
         double_gt_unlock(lgt, rgt);
 
-    op->dev_bus_addr = mfn_to_maddr(mfn);
+    op->dev_bus_addr = paging_mode_translate(ld) ? op->host_addr
+                                                 : mfn_to_maddr(mfn);
     op->handle       = handle;
     op->status       = GNTST_okay;
 
@@ -1382,7 +1391,7 @@ unmap_common(
 
     op->mfn = act->mfn;
 
-    if ( op->dev_bus_addr &&
+    if ( op->dev_bus_addr && (flags & GNTMAP_device_map) &&
          unlikely(op->dev_bus_addr != mfn_to_maddr(act->mfn)) )
         PIN_FAIL(act_release_out, GNTST_general_error,
                  "Bus address doesn't match gntref (%"PRIx64" != %"PRIpaddr")\n",


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

      parent reply	other threads:[~2019-11-25  9:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-25  9:55 [Xen-devel] [PATCH v3 0/3] AMD/IOMMU: re-work mode updating Jan Beulich
2019-11-25  9:57 ` [Xen-devel] [PATCH v3 1/3] introduce GFN notification for translated domains Jan Beulich
2019-11-25 10:37   ` Durrant, Paul
2019-11-25 10:51     ` Jan Beulich
2019-11-25 10:53       ` Durrant, Paul
2019-11-25  9:58 ` [Xen-devel] [PATCH v3 2/3] AMD/IOMMU: use notify_dfn() hook to update paging mode Jan Beulich
2019-11-25  9:59 ` Jan Beulich [this message]

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=1dcb0914-bdbb-6ffa-572b-c91b0ecdc5b3@suse.com \
    --to=jbeulich@suse.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ian.jackson@citrix.com \
    --cc=jgross@suse.com \
    --cc=julien@xen.org \
    --cc=konrad.wilk@oracle.com \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.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 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.