[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH v2] x86/hvm: be more strict with XENMAPSPACE_gmfn source types


  • To: xen-devel@xxxxxxxxxxxxxxxxxxxx
  • From: Roger Pau Monne <roger.pau@xxxxxxxxxx>
  • Date: Wed, 7 Jan 2026 21:32:59 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=S3BJtMRKxVuXEnoIV9FOzi+tgLxVenbBPFNkP9YtRQ0=; b=cW4+NsxCGEnDvWLRPx4uENGf9mfHawSqk8xgy5yo/y24afsYHYlTyqQZ9tDZqKQmT1I7Inls95k8T1J27vkGAIrfmBTLCyCkpXH+zvCNuwueY8RtXOrSId8gDct40xtubNGvpwHN0TZAXm5hffIvz2Lc5Spi16V2YJ2Q1PMZfrYPG6znPYt5Y4ynJSkQljL+c4Uf9YfjPKwjtm5hP4rmthyU/ae71NkZmXua1ppVLDEpOCqzBzr7vOuHEKYaCt9dmbVr4Z2Jn3yMH6XtYjD4hoNt1KLGu1wO5OBoNP19Gar6uGL1me5N9NqqSsCMR0x//POh28gba1aUPTBbOWThPQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ZgUtDQ9oUgampNK88UBgjvEnAuAoGR/5iE+ZJ2B+oJMDf5nD2Qi3WKBXas4GVYjTHaB6b4HevMLST1ImnBhwqnofDJQX9Y/n4fYebq+Vd7P2pfGwTYhIijJsAzWuQquBYpsymufQmUVmnvz/wkGagi3s2UTTUYdZYl45En/bxACqcljptU3g3faNCveu6f0wUB2OPkODsjAbwCFfU4X/0wYhwOaxpo/7XdJdynSj81y96oIg/544ijsT8xFpbnvf92ak1+CUAsoRwy3Q7NhpW25f7Xp6UxQNJA2rTAENeRupLYIXENp4xxKyyMPTIfKq37/BrXLoJqa/R1RF20yCZQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Roger Pau Monne <roger.pau@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Delivery-date: Wed, 07 Jan 2026 20:33:41 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

XENMAPSPACE_gmfn{_range} allows moving gfn around the guest p2m: the mfn
behind the source gfn is zapped from the origin and mapped at the
requested destination gfn.  The destination p2m entries are always created
with type p2m_ram_rw.

With the current checking done in xenmem_add_to_physmap_one() it's possible
to use XENMAPSPACE_gmfn{_range} to change the type of a p2m entry.  The
source gfn is only checked to be not shared, and that the underlying page
is owned by the domain.

Make the source checks more strict, by checking that the source gfn is of
type read/write RAM or logdirty.  That prevents the operation from
inadvertently changing the type as part of the move.

Fixes: 3e50af3d8776 ('New XENMAPSPACE_gmfn parameter for 
XENMEM_add_to_physmap.')
Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
---
Changes since v1:
 - Also handle logdirty types.
 - Return -ENOMEM on failure to unshare.
---
 xen/arch/x86/mm/p2m.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 2433230ac71c..759f3273d3d8 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -2015,11 +2015,17 @@ int xenmem_add_to_physmap_one(
     {
         gmfn = idx;
         mfn = get_gfn_unshare(d, gmfn, &p2mt);
-        /* If the page is still shared, exit early */
-        if ( p2m_is_shared(p2mt) )
+        /*
+         * The entry at the destination gfn will be created as type p2m_ram_rw.
+         * Only allow moving source gfns with read/write or logdirty RAM types
+         * to avoid unexpected p2m type changes as a result of the operation.
+         * Note that for logdirty source type we rely on p2m_add_page() marking
+         * the destination gfn as dirty.
+         */
+        if ( p2mt != p2m_ram_rw && p2mt != p2m_ram_logdirty )
         {
             put_gfn(d, gmfn);
-            return -ENOMEM;
+            return p2m_is_shared(p2mt) ? -ENOMEM : -EACCES;
         }
         page = get_page_from_mfn(mfn, d);
         if ( unlikely(!page) )
-- 
2.51.0




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.