update to xen-4.15.4

adjust xen.canonicalize.patch
remove or adjust patches now included or superceded upstream
x86: Multiple speculative security issues [XSA-422, CVE-2022-23824]

.gitignore

@@ -6,4 +6,4 @@ lwip-1.3.0.tar.gz
 pciutils-2.2.9.tar.bz2
 zlib-1.2.3.tar.gz
 polarssl-1.1.4-gpl.tgz
-/xen-4.15.1.tar.gz
+/xen-4.15.4.tar.gz

sources

@@ -4,4 +4,4 @@ SHA512 (newlib-1.16.0.tar.gz) = 40eb96bbc6736a16b6399e0cdb73e853d0d90b685c967e77
 SHA512 (zlib-1.2.3.tar.gz) = 021b958fcd0d346c4ba761bcf0cc40f3522de6186cf5a0a6ea34a70504ce9622b1c2626fce40675bc8282cf5f5ade18473656abc38050f72f5d6480507a2106e
 SHA512 (polarssl-1.1.4-gpl.tgz) = 88da614e4d3f4409c4fd3bb3e44c7587ba051e3fed4e33d526069a67e8180212e1ea22da984656f50e290049f60ddca65383e5983c0f8884f648d71f698303ad
 SHA512 (pciutils-2.2.9.tar.bz2) = 2b3d98d027e46d8c08037366dde6f0781ca03c610ef2b380984639e4ef39899ed8d8b8e4cd9c9dc54df101279b95879bd66bfd4d04ad07fef41e847ea7ae32b5
-SHA512 (xen-4.15.1.tar.gz) = 8d3cbdf708f46477e32ee7cbd16a490c82efa855cecd84ee712b8680df4d69c987ba9ab00ff3851f627b98a8ebbc5dab71f92f142ed958ee2bc538bc792cd4b9
+SHA512 (xen-4.15.4.tar.gz) = fa6a4991c0699025af163ed117f8d0523c0a482102464615025eb3575d755ffacec5df394e3fe01871cde6028678f654d99f8e3c2533b138765971a2a7994cb8

xen.canonicalize.patch

@@ -13,8 +13,8 @@
  	if (get_strings(in, vec, ARRAY_SIZE(vec)) != ARRAY_SIZE(vec))
  		return EINVAL;
  
--	node = canonicalize(conn, in, vec[0]);
-+	node = xenstore_canonicalize(conn, in, vec[0]);
+-	node = canonicalize(conn, ctx, vec[0]);
++	node = xenstore_canonicalize(conn, ctx, vec[0]);
  	if (!node)
  		return ENOMEM;
  	list_for_each_entry(watch, &conn->watches, list) {

xen.spec

@@ -57,8 +57,8 @@
 
 Summary: Xen is a virtual machine monitor
 Name:    xen
-Version: 4.15.1
-Release: 4%{?dist}
+Version: 4.15.4
+Release: 1%{?dist}
 License: GPLv2+ and LGPLv2+ and BSD
 URL:     http://xen.org/
 Source0: https://downloads.xenproject.org/release/xen/%{version}/xen-%{version}.tar.gz
@@ -113,12 +113,7 @@ Patch41: xen.gcc9.fixes.patch
 Patch42: xen.gcc10.fixes.patch
 Patch43: xen.gcc11.fixes.patch
 Patch44: xen.ocaml.4.12.fixes.patch
-Patch45: xsa386.patch
-Patch46: xsa385-4.15.patch
-Patch47: xsa388-4.15-1.patch
-Patch48: xsa388-4.15-2.patch
-Patch49: xsa389-4.15.patch
-Patch50: xsa390.patch
+Patch51: xsa376.patch
 
 
 %if %build_qemutrad
@@ -328,12 +323,7 @@ manage Xen virtual machines.
 %patch42 -p1
 %patch43 -p1
 %patch44 -p1
-%patch45 -p1
-%patch46 -p1
-%patch47 -p1
-%patch48 -p1
-%patch49 -p1
-%patch50 -p1
+%patch51 -p1
 
 # qemu-xen-traditional patches
 pushd tools/qemu-xen-traditional
@@ -929,6 +919,93 @@ fi
 %endif
 
 %changelog
+* Wed Nov 16 2022 Michael Young <m.a.young@durham.ac.uk> - 4.15.4-1
+- update to xen-4.15.4
+  adjust xen.canonicalize.patch
+  remove or adjust patches now included or superceded upstream
+- x86: Multiple speculative security issues [XSA-422, CVE-2022-23824]
+
+* Tue Nov 01 2022 Michael Young <m.a.young@durham.ac.uk> - 4.15.3-7
+- Xenstore: Guests can crash xenstored [XSA-414, CVE-2022-42309]
+- Xenstore: Guests can create orphaned Xenstore nodes [XSA-415,
+        CVE-2022-42310]
+- Xenstore: guests can let run xenstored out of memory [XSA-326,
+        CVE-2022-42311, CVE-2022-42312, CVE-2022-42313, CVE-2022-42314,
+        CVE-2022-42315, CVE-2022-42316, CVE-2022-42317, CVE-2022-42318]
+- Xenstore: Guests can cause Xenstore to not free temporary memory
+        [XSA-416, CVE-2022-42319]
+- Xenstore: Guests can get access to Xenstore nodes of deleted domains
+        [XSA-417, CVE-2022-42320]
+- Xenstore: Guests can crash xenstored via exhausting the stack
+        [XSA-418, CVE-2022-42321]
+- Xenstore: Cooperating guests can create arbitrary numbers of nodes
+        [XSA-419, CVE-2022-42322, CVE-2022-42323]
+- Oxenstored 32->31 bit integer truncation issues [XSA-420, CVE-2022-42324]
+- Xenstore: Guests can create arbitrary number of nodes via transactions
+        [XSA-421, CVE-2022-42325, CVE-2022-42326]
+
+* Tue Oct 18 2022 Michael Young <m.a.young@durham.ac.uk> - 4.15.3-6
+- add patch to fix an incorrect backport
+
+* Tue Oct 18 2022 Michael Young <m.a.young@durham.ac.uk> - 4.15.3-5
+- Arm: unbounded memory consumption for 2nd-level page tables [XSA-409,
+	CVE-2022-33747] (#2135268)
+- P2M pool freeing may take excessively long [XSA-410, CVE-2022-33746]
+	(#2135641)
+- lock order inversion in transitive grant copy handling [XSA-411,
+	CVE-2022-33748] (#2135263)
+
+* Tue Jul 26 2022 Michael Young <m.a.young@durham.ac.uk> - 4.15.3-4
+- insufficient TLB flush for x86 PV guests in shadow mode [XSA-408,
+        CVE-2022-33745] (#2112223)
+
+* Fri Jul 22 2022 Michael Young <m.a.young@durham.ac.uk> - 4.15.3-3
+- Retbleed - arbitrary speculative code execution with return instructions
+        [XSA-407, CVE-2022-23816, CVE-2022-23825, CVE-2022-29900]
+
+* Thu Jul 07 2022 Michael Young <m.a.young@durham.ac.uk> - 4.15.3-2
+- Linux disk/nic frontends data leaks [XSA-403, CVE-2022-26365,
+	CVE-2022-33740, CVE-2022-33741, CVE-2022-33742] (#2104747)
+
+* Fri Jul 01 2022 Michael Young <m.a.young@durham.ac.uk> - 4.15.3-1
+- update to xen-4.15.3
+  remove or adjust patches now included or superceded upstream
+- x86: MMIO Stale Data vulnerabilities (not applied in 4.15.2-5)
+
+* Wed Jun 22 2022 Michael Young <m.a.young@durham.ac.uk> - 4.15.2-5
+- x86: MMIO Stale Data vulnerabilities [XSA-404, CVE-2022-21123,
+	CVE-2022-21125, CVE-2022-21166]
+
+* Thu Jun 09 2022 Michael Young <m.a.young@durham.ac.uk> - 4.15.2-4
+- x86 pv: Race condition in typeref acquisition [XSA-401, CVE-2022-26362]
+- x86 pv: Insufficient care with non-coherent mappings [ XSA-402,
+	CVE-2022-26363, CVE-2022-26364]
+- additional patches so above applies cleanly
+
+* Wed Apr 06 2022 Michael Young <m.a.young@durham.ac.uk> - 4.15.2-3
+- Racy interactions between dirty vram tracking and paging log dirty
+	hypercalls [XSA-397, CVE-2022-26356]
+- race in VT-d domain ID cleanup [XSA-399, CVE-2022-26357]
+- IOMMU: RMRR (VT-d) and unity map (AMD-Vi) handling issues [XSA-400,
+	CVE-2022-26358, CVE-2022-26359, CVE-2022-26360, CVE-2022-26361]
+
+* Sat Mar 12 2022 Michael Young <m.a.young@durham.ac.uk> - 4.15.2-2
+- Multiple speculative security issues [XSA-398]
+- additional patches so above applies cleanly
+
+* Thu Feb 03 2022 Michael Young <m.a.young@durham.ac.uk> - 4.15.2-1
+- update to xen-4.15.2
+  remove or adjust patches now included or superceded upstream
+
+* Tue Jan 25 2022 Michael Young <m.a.young@durham.ac.uk> - 4.15.1-5
+- frontends vulnerable to backends [XSA-376] (document change only)
+- arm: guest_physmap_remove_page not removing the p2m mappings [XSA-393,
+	CVE-2022-23033] (#2045044)
+- A PV guest could DoS Xen while unmapping a grant [XSA-394, CVE-2022-23034]
+	(#2045042)
+- Insufficient cleanup of passed-through device IRQs [XSA-395,
+	CVE-2022-23035] (#2045040)
+
 * Tue Nov 23 2021 Michael Young <m.a.young@durham.ac.uk> - 4.15.1-4
 - guests may exceed their designated memory limit [XSA-385, CVE-2021-28706]
 - PoD operations on misaligned GFNs [XSA-388, CVE-2021-28704, CVE-2021-28707

xsa376.patch

@@ -0,0 +1,145 @@
+From 02d3a57d6466363b316b60ffbba414a4a2cb90c5 Mon Sep 17 00:00:00 2001
+From: Juergen Gross <jgross@suse.com>
+Date: Thu, 25 Nov 2021 13:38:29 +0100
+Subject: [PATCH] SUPPORT.md: limit support statement for Linux and Windows
+ frontends
+
+Change the support state of Linux and Windows pv frontends from
+"supported" to "supported with caveats" in order to reflect that the
+frontends can probably be harmed by their respective backends.
+
+Some of the Linux frontends have been hardened already.
+
+This is XSA-376
+
+Signed-off-by: Juergen Gross <jgross@suse.com>
+---
+ SUPPORT.md | 57 +++++++++++++++++++++++++++++++++++++++++++++---------
+ 1 file changed, 48 insertions(+), 9 deletions(-)
+
+diff --git a/SUPPORT.md b/SUPPORT.md
+index 3a34933c89..6e3e305b01 100644
+--- a/SUPPORT.md
++++ b/SUPPORT.md
+@@ -411,7 +411,11 @@ Guest-side driver capable of speaking the Xen PV block protocol
+     Status, FreeBSD: Supported, Security support external
+     Status, NetBSD: Supported, Security support external
+     Status, OpenBSD: Supported, Security support external
+-    Status, Windows: Supported
++    Status, Windows: Supported, with caveats
++
++Windows frontend currently trusts the backend;
++bugs in the frontend which allow backend to cause mischief will not be
++considered security vulnerabilities.
+ 
+ ### Netfront
+ 
+@@ -421,20 +425,32 @@ Guest-side driver capable of speaking the Xen PV networking protocol
+     Status, FreeBSD: Supported, Security support external
+     Status, NetBSD: Supported, Security support external
+     Status, OpenBSD: Supported, Security support external
+-    Status, Windows: Supported
++    Status, Windows: Supported, with caveats
++
++Windows frontend currently trusts the backend;
++bugs in the frontend which allow backend to cause mischief will not be
++considered security vulnerabilities.
+ 
+ ### PV Framebuffer (frontend)
+ 
+ Guest-side driver capable of speaking the Xen PV Framebuffer protocol
+ 
+-    Status, Linux (xen-fbfront): Supported
++    Status, Linux (xen-fbfront): Supported, with caveats
++
++Linux frontend currently trusts the backend;
++bugs in the frontend which allow backend to cause mischief will not be
++considered security vulnerabilities.
+ 
+ ### PV display (frontend)
+ 
+ Guest-side driver capable of speaking the Xen PV display protocol
+ 
+-    Status, Linux: Supported (outside of "backend allocation" mode)
+-    Status, Linux: Experimental (in "backend allocation" mode)
++    Status, Linux, outside of "backend allocation" mode: Supported, with caveats
++    Status, Linux, "backend allocation" mode: Experimental
++
++Linux frontend currently trusts the backend;
++bugs in the frontend which allow backend to cause mischief will not be
++considered security vulnerabilities.
+ 
+ ### PV Console (frontend)
+ 
+@@ -443,7 +459,11 @@ Guest-side driver capable of speaking the Xen PV console protocol
+     Status, Linux (hvc_xen): Supported
+     Status, FreeBSD: Supported, Security support external
+     Status, NetBSD: Supported, Security support external
+-    Status, Windows: Supported
++    Status, Windows: Supported, with caveats
++
++Windows frontend currently trusts the backend;
++bugs in the frontend which allow backend to cause mischief will not be
++considered security vulnerabilities.
+ 
+ ### PV keyboard (frontend)
+ 
+@@ -451,11 +471,19 @@ Guest-side driver capable of speaking the Xen PV keyboard protocol.
+ Note that the "keyboard protocol" includes mouse / pointer /
+ multi-touch support as well.
+ 
+-    Status, Linux (xen-kbdfront): Supported
++    Status, Linux (xen-kbdfront): Supported, with caveats
++
++Linux frontend currently trusts the backend;
++bugs in the frontend which allow backend to cause mischief will not be
++considered security vulnerabilities.
+ 
+ ### PV USB (frontend)
+ 
+-    Status, Linux: Supported
++    Status, Linux: Supported, with caveats
++
++Linux frontend currently trusts the backend;
++bugs in the frontend which allow backend to cause mischief will not be
++considered security vulnerabilities.
+ 
+ ### PV SCSI protocol (frontend)
+ 
+@@ -464,6 +492,10 @@ multi-touch support as well.
+ NB that while the PV SCSI frontend is in Linux and tested regularly,
+ there is currently no xl support.
+ 
++Linux frontend currently trusts the backend;
++bugs in the frontend which allow backend to cause mischief will not be
++considered security vulnerabilities.
++
+ ### PV TPM (frontend)
+ 
+ Guest-side driver capable of speaking the Xen PV TPM protocol
+@@ -486,7 +518,11 @@ Guest-side driver capable of making pv system calls
+ 
+ Guest-side driver capable of speaking the Xen PV sound protocol
+ 
+-    Status, Linux: Supported
++    Status, Linux: Supported, with caveats
++
++Linux frontend currently trusts the backend;
++bugs in the frontend which allow backend to cause mischief will not be
++considered security vulnerabilities.
+ 
+ ## Virtual device support, host side
+ 
+@@ -987,6 +1023,9 @@ are given the following labels:
+ 
+     This feature is security supported
+     by a different organization (not the XenProject).
++    The extent of support is defined by that organization.
++    It might be limited, e.g. like described in **Supported, with caveats**
++    below.
+     See **External security support** below.
+ 
+   * **Supported, with caveats**
+-- 
+2.26.2
+

xsa385-4.15.patch

@@ -1,96 +0,0 @@
-From: Julien Grall <jgrall@amazon.com>
-Subject: xen/page_alloc: Harden assign_pages()
-
-domain_tot_pages() and d->max_pages are 32-bit values. While the order
-should always be quite small, it would still be possible to overflow
-if domain_tot_pages() is near to (2^32 - 1).
-
-As this code may be called by a guest via XENMEM_increase_reservation
-and XENMEM_populate_physmap, we want to make sure the guest is not going
-to be able to allocate more than it is allowed.
-
-Rework the allocation check to avoid any possible overflow. While the
-check domain_tot_pages() < d->max_pages should technically not be
-necessary, it is probably best to have it to catch any possible
-inconsistencies in the future.
-
-This is CVE-2021-28706 / XSA-385.
-
-Signed-off-by: Julien Grall <jgrall@amazon.com>
-Signed-off-by: Jan Beulich <jbeulich@suse.com>
-
---- a/xen/common/grant_table.c
-+++ b/xen/common/grant_table.c
-@@ -2336,7 +2336,8 @@ gnttab_transfer(
-          * pages when it is dying.
-          */
-         if ( unlikely(e->is_dying) ||
--             unlikely(domain_tot_pages(e) >= e->max_pages) )
-+             unlikely(domain_tot_pages(e) >= e->max_pages) ||
-+             unlikely(!(e->tot_pages + 1)) )
-         {
-             spin_unlock(&e->page_alloc_lock);
- 
-@@ -2345,8 +2346,8 @@ gnttab_transfer(
-                          e->domain_id);
-             else
-                 gdprintk(XENLOG_INFO,
--                         "Transferee d%d has no headroom (tot %u, max %u)\n",
--                         e->domain_id, domain_tot_pages(e), e->max_pages);
-+                         "Transferee %pd has no headroom (tot %u, max %u, ex %u)\n",
-+                         e, domain_tot_pages(e), e->max_pages, e->extra_pages);
- 
-             gop.status = GNTST_general_error;
-             goto unlock_and_copyback;
---- a/xen/common/page_alloc.c
-+++ b/xen/common/page_alloc.c
-@@ -2298,20 +2298,43 @@ int assign_pages(
-     }
-     else if ( !(memflags & MEMF_no_refcount) )
-     {
--        unsigned int tot_pages = domain_tot_pages(d) + (1 << order);
-+        unsigned int tot_pages = domain_tot_pages(d), nr = 1u << order;
- 
-         if ( unlikely(tot_pages > d->max_pages) )
-         {
--            gprintk(XENLOG_INFO, "Over-allocation for domain %u: "
--                    "%u > %u\n", d->domain_id, tot_pages, d->max_pages);
-+            gprintk(XENLOG_INFO, "Inconsistent allocation for %pd: %u > %u\n",
-+                    d, tot_pages, d->max_pages);
-+            rc = -EPERM;
-+            goto out;
-+        }
-+
-+        if ( unlikely(nr > d->max_pages - tot_pages) )
-+        {
-+            gprintk(XENLOG_INFO, "Over-allocation for %pd: %Lu > %u\n",
-+                    d, tot_pages + 0ull + nr, d->max_pages);
-             rc = -E2BIG;
-             goto out;
-         }
-     }
- 
--    if ( !(memflags & MEMF_no_refcount) &&
--         unlikely(domain_adjust_tot_pages(d, 1 << order) == (1 << order)) )
--        get_knownalive_domain(d);
-+    if ( !(memflags & MEMF_no_refcount) )
-+    {
-+        unsigned int nr = 1u << order;
-+
-+        if ( unlikely(d->tot_pages + nr < nr) )
-+        {
-+            gprintk(XENLOG_INFO,
-+                    "Excess allocation for %pd: %Lu (%u extra)\n",
-+                    d, d->tot_pages + 0ull + nr, d->extra_pages);
-+            if ( pg[0].count_info & PGC_extra )
-+                d->extra_pages -= nr;
-+            rc = -E2BIG;
-+            goto out;
-+        }
-+
-+        if ( unlikely(domain_adjust_tot_pages(d, nr) == nr) )
-+            get_knownalive_domain(d);
-+    }
- 
-     for ( i = 0; i < (1 << order); i++ )
-     {

xsa386.patch

@@ -1,29 +0,0 @@
-From: Jan Beulich <jbeulich@suse.com>
-Subject: VT-d: fix deassign of device with RMRR
-Date: Fri, 1 Oct 2021 15:05:42 +0200
-
-Ignoring a specific error code here was not meant to short circuit
-deassign to _just_ the unmapping of RMRRs. This bug was previously
-hidden by the bogus (potentially indefinite) looping in
-pci_release_devices(), until f591755823a7 ("IOMMU/PCI: don't let domain
-cleanup continue when device de-assignment failed") fixed that loop.
-
-This is CVE-2021-28702 / XSA-386.
-
-Fixes: 8b99f4400b69 ("VT-d: fix RMRR related error handling")
-Reported-by: Ivan Kardykov <kardykov@tabit.pro>
-Signed-off-by: Jan Beulich <jbeulich@suse.com>
-Tested-by: Ivan Kardykov <kardykov@tabit.pro>
-
---- a/xen/drivers/passthrough/vtd/iommu.c
-+++ b/xen/drivers/passthrough/vtd/iommu.c
-@@ -2409,7 +2409,7 @@ static int reassign_device_ownership(
-                 ret = iommu_identity_mapping(source, p2m_access_x,
-                                              rmrr->base_address,
-                                              rmrr->end_address, 0);
--                if ( ret != -ENOENT )
-+                if ( ret && ret != -ENOENT )
-                     return ret;
-             }
-     }
-

xsa388-4.15-1.patch

@@ -1,174 +0,0 @@
-From: Jan Beulich <jbeulich@suse.com>
-Subject: x86/PoD: deal with misaligned GFNs
-
-Users of XENMEM_decrease_reservation and XENMEM_populate_physmap aren't
-required to pass in order-aligned GFN values. (While I consider this
-bogus, I don't think we can fix this there, as that might break existing
-code, e.g Linux'es swiotlb, which - while affecting PV only - until
-recently had been enforcing only page alignment on the original
-allocation.) Only non-PoD code paths (guest_physmap_{add,remove}_page(),
-p2m_set_entry()) look to be dealing with this properly (in part by being
-implemented inefficiently, handling every 4k page separately).
-
-Introduce wrappers taking care of splitting the incoming request into
-aligned chunks, without putting much effort in trying to determine the
-largest possible chunk at every iteration.
-
-Also "handle" p2m_set_entry() failure for non-order-0 requests by
-crashing the domain in one more place. Alongside putting a log message
-there, also add one to the other similar path.
-
-Note regarding locking: This is left in the actual worker functions on
-the assumption that callers aren't guaranteed atomicity wrt acting on
-multiple pages at a time. For mis-aligned GFNs gfn_lock() wouldn't have
-locked the correct GFN range anyway, if it didn't simply resolve to
-p2m_lock(), and for well-behaved callers there continues to be only a
-single iteration, i.e. behavior is unchanged for them. (FTAOD pulling
-out just pod_lock() into p2m_pod_decrease_reservation() would result in
-a lock order violation.)
-
-This is CVE-2021-28704 and CVE-2021-28707 / part of XSA-388.
-
-Fixes: 3c352011c0d3 ("x86/PoD: shorten certain operations on higher order ranges")
-Signed-off-by: Jan Beulich <jbeulich@suse.com>
-Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
-
---- a/xen/arch/x86/mm/p2m-pod.c
-+++ b/xen/arch/x86/mm/p2m-pod.c
-@@ -496,7 +496,7 @@ p2m_pod_zero_check_superpage(struct p2m_
- 
- 
- /*
-- * This function is needed for two reasons:
-+ * This pair of functions is needed for two reasons:
-  * + To properly handle clearing of PoD entries
-  * + To "steal back" memory being freed for the PoD cache, rather than
-  *   releasing it.
-@@ -504,8 +504,8 @@ p2m_pod_zero_check_superpage(struct p2m_
-  * Once both of these functions have been completed, we can return and
-  * allow decrease_reservation() to handle everything else.
-  */
--unsigned long
--p2m_pod_decrease_reservation(struct domain *d, gfn_t gfn, unsigned int order)
-+static unsigned long
-+decrease_reservation(struct domain *d, gfn_t gfn, unsigned int order)
- {
-     unsigned long ret = 0, i, n;
-     struct p2m_domain *p2m = p2m_get_hostp2m(d);
-@@ -552,8 +552,10 @@ p2m_pod_decrease_reservation(struct doma
-          * All PoD: Mark the whole region invalid and tell caller
-          * we're done.
-          */
--        if ( p2m_set_entry(p2m, gfn, INVALID_MFN, order, p2m_invalid,
--                           p2m->default_access) )
-+        int rc = p2m_set_entry(p2m, gfn, INVALID_MFN, order, p2m_invalid,
-+                               p2m->default_access);
-+
-+        if ( rc )
-         {
-             /*
-              * If this fails, we can't tell how much of the range was changed.
-@@ -561,7 +563,12 @@ p2m_pod_decrease_reservation(struct doma
-              * impossible.
-              */
-             if ( order != 0 )
-+            {
-+                printk(XENLOG_G_ERR
-+                       "%pd: marking GFN %#lx (order %u) as non-PoD failed: %d\n",
-+                       d, gfn_x(gfn), order, rc);
-                 domain_crash(d);
-+            }
-             goto out_unlock;
-         }
-         ret = 1UL << order;
-@@ -670,6 +677,22 @@ out_unlock:
-     return ret;
- }
- 
-+unsigned long
-+p2m_pod_decrease_reservation(struct domain *d, gfn_t gfn, unsigned int order)
-+{
-+    unsigned long left = 1UL << order, ret = 0;
-+    unsigned int chunk_order = find_first_set_bit(gfn_x(gfn) | left);
-+
-+    do {
-+        ret += decrease_reservation(d, gfn, chunk_order);
-+
-+        left -= 1UL << chunk_order;
-+        gfn = gfn_add(gfn, 1UL << chunk_order);
-+    } while ( left );
-+
-+    return ret;
-+}
-+
- void p2m_pod_dump_data(struct domain *d)
- {
-     struct p2m_domain *p2m = p2m_get_hostp2m(d);
-@@ -1273,19 +1296,15 @@ remap_and_retry:
-     return true;
- }
- 
--
--int
--guest_physmap_mark_populate_on_demand(struct domain *d, unsigned long gfn_l,
--                                      unsigned int order)
-+static int
-+mark_populate_on_demand(struct domain *d, unsigned long gfn_l,
-+                        unsigned int order)
- {
-     struct p2m_domain *p2m = p2m_get_hostp2m(d);
-     gfn_t gfn = _gfn(gfn_l);
-     unsigned long i, n, pod_count = 0;
-     int rc = 0;
- 
--    if ( !paging_mode_translate(d) )
--        return -EINVAL;
--
-     gfn_lock(p2m, gfn, order);
- 
-     P2M_DEBUG("mark pod gfn=%#lx\n", gfn_l);
-@@ -1325,12 +1344,44 @@ guest_physmap_mark_populate_on_demand(st
- 
-         ioreq_request_mapcache_invalidate(d);
-     }
-+    else if ( order )
-+    {
-+        /*
-+         * If this failed, we can't tell how much of the range was changed.
-+         * Best to crash the domain.
-+         */
-+        printk(XENLOG_G_ERR
-+               "%pd: marking GFN %#lx (order %u) as PoD failed: %d\n",
-+               d, gfn_l, order, rc);
-+        domain_crash(d);
-+    }
- 
- out:
-     gfn_unlock(p2m, gfn, order);
- 
-     return rc;
- }
-+
-+int
-+guest_physmap_mark_populate_on_demand(struct domain *d, unsigned long gfn,
-+                                      unsigned int order)
-+{
-+    unsigned long left = 1UL << order;
-+    unsigned int chunk_order = find_first_set_bit(gfn | left);
-+    int rc;
-+
-+    if ( !paging_mode_translate(d) )
-+        return -EINVAL;
-+
-+    do {
-+        rc = mark_populate_on_demand(d, gfn, chunk_order);
-+
-+        left -= 1UL << chunk_order;
-+        gfn += 1UL << chunk_order;
-+    } while ( !rc && left );
-+
-+    return rc;
-+}
- 
- void p2m_pod_init(struct p2m_domain *p2m)
- {

xsa388-4.15-2.patch

@@ -1,36 +0,0 @@
-From: Jan Beulich <jbeulich@suse.com>
-Subject: x86/PoD: handle intermediate page orders in p2m_pod_cache_add()
-
-p2m_pod_decrease_reservation() may pass pages to the function which
-aren't 4k, 2M, or 1G. Handle all intermediate orders as well, to avoid
-hitting the BUG() at the switch() statement's "default" case.
-
-This is CVE-2021-28708 / part of XSA-388.
-
-Fixes: 3c352011c0d3 ("x86/PoD: shorten certain operations on higher order ranges")
-Signed-off-by: Jan Beulich <jbeulich@suse.com>
-Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
-
---- a/xen/arch/x86/mm/p2m-pod.c
-+++ b/xen/arch/x86/mm/p2m-pod.c
-@@ -112,15 +112,13 @@ p2m_pod_cache_add(struct p2m_domain *p2m
-     /* Then add to the appropriate populate-on-demand list. */
-     switch ( order )
-     {
--    case PAGE_ORDER_1G:
--        for ( i = 0; i < (1UL << PAGE_ORDER_1G); i += 1UL << PAGE_ORDER_2M )
-+    case PAGE_ORDER_2M ... PAGE_ORDER_1G:
-+        for ( i = 0; i < (1UL << order); i += 1UL << PAGE_ORDER_2M )
-             page_list_add_tail(page + i, &p2m->pod.super);
-         break;
--    case PAGE_ORDER_2M:
--        page_list_add_tail(page, &p2m->pod.super);
--        break;
--    case PAGE_ORDER_4K:
--        page_list_add_tail(page, &p2m->pod.single);
-+    case PAGE_ORDER_4K ... PAGE_ORDER_2M - 1:
-+        for ( i = 0; i < (1UL << order); i += 1UL << PAGE_ORDER_4K )
-+            page_list_add_tail(page + i, &p2m->pod.single);
-         break;
-     default:
-         BUG();

xsa389-4.15.patch

@@ -1,182 +0,0 @@
-From: Jan Beulich <jbeulich@suse.com>
-Subject: x86/P2M: deal with partial success of p2m_set_entry()
-
-M2P and PoD stats need to remain in sync with P2M; if an update succeeds
-only partially, respective adjustments need to be made. If updates get
-made before the call, they may also need undoing upon complete failure
-(i.e. including the single-page case).
-
-Log-dirty state would better also be kept in sync.
-
-Note that the change to set_typed_p2m_entry() may not be strictly
-necessary (due to the order restriction enforced near the top of the
-function), but is being kept here to be on the safe side.
-
-This is CVE-2021-28705 and CVE-2021-28709 / XSA-389.
-
-Signed-off-by: Jan Beulich <jbeulich@suse.com>
-Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
-
---- a/xen/arch/x86/mm/p2m.c
-+++ b/xen/arch/x86/mm/p2m.c
-@@ -784,6 +784,7 @@ p2m_remove_page(struct p2m_domain *p2m,
-     unsigned long i;
-     p2m_type_t t;
-     p2m_access_t a;
-+    int rc;
- 
-     /* IOMMU for PV guests is handled in get_page_type() and put_page(). */
-     if ( !paging_mode_translate(p2m->domain) )
-@@ -819,8 +820,27 @@ p2m_remove_page(struct p2m_domain *p2m,
- 
-     ioreq_request_mapcache_invalidate(p2m->domain);
- 
--    return p2m_set_entry(p2m, gfn, INVALID_MFN, page_order, p2m_invalid,
--                         p2m->default_access);
-+    rc = p2m_set_entry(p2m, gfn, INVALID_MFN, page_order, p2m_invalid,
-+                       p2m->default_access);
-+    if ( likely(!rc) || !mfn_valid(mfn) )
-+        return rc;
-+
-+    /*
-+     * The operation may have partially succeeded. For the failed part we need
-+     * to undo the M2P update and, out of precaution, mark the pages dirty
-+     * again.
-+     */
-+    for ( i = 0; i < (1UL << page_order); ++i )
-+    {
-+        p2m->get_entry(p2m, gfn_add(gfn, i), &t, &a, 0, NULL, NULL);
-+        if ( !p2m_is_hole(t) && !p2m_is_special(t) && !p2m_is_shared(t) )
-+        {
-+            set_gpfn_from_mfn(mfn_x(mfn) + i, gfn_x(gfn) + i);
-+            paging_mark_pfn_dirty(p2m->domain, _pfn(gfn_x(gfn) + i));
-+        }
-+    }
-+
-+    return rc;
- }
- 
- int
-@@ -1009,13 +1029,8 @@ guest_physmap_add_entry(struct domain *d
- 
-     /* Now, actually do the two-way mapping */
-     rc = p2m_set_entry(p2m, gfn, mfn, page_order, t, p2m->default_access);
--    if ( rc == 0 )
-+    if ( likely(!rc) )
-     {
--        pod_lock(p2m);
--        p2m->pod.entry_count -= pod_count;
--        BUG_ON(p2m->pod.entry_count < 0);
--        pod_unlock(p2m);
--
-         if ( !p2m_is_grant(t) )
-         {
-             for ( i = 0; i < (1UL << page_order); i++ )
-@@ -1023,6 +1038,42 @@ guest_physmap_add_entry(struct domain *d
-                                   gfn_x(gfn_add(gfn, i)));
-         }
-     }
-+    else
-+    {
-+        /*
-+         * The operation may have partially succeeded. For the successful part
-+         * we need to update M2P and dirty state, while for the failed part we
-+         * may need to adjust PoD stats as well as undo the earlier M2P update.
-+         */
-+        for ( i = 0; i < (1UL << page_order); ++i )
-+        {
-+            omfn = p2m->get_entry(p2m, gfn_add(gfn, i), &ot, &a, 0, NULL, NULL);
-+            if ( p2m_is_pod(ot) )
-+            {
-+                BUG_ON(!pod_count);
-+                --pod_count;
-+            }
-+            else if ( mfn_eq(omfn, mfn_add(mfn, i)) && ot == t &&
-+                      a == p2m->default_access && !p2m_is_grant(t) )
-+            {
-+                set_gpfn_from_mfn(mfn_x(omfn), gfn_x(gfn) + i);
-+                paging_mark_pfn_dirty(d, _pfn(gfn_x(gfn) + i));
-+            }
-+            else if ( p2m_is_ram(ot) && !p2m_is_paged(ot) )
-+            {
-+                ASSERT(mfn_valid(omfn));
-+                set_gpfn_from_mfn(mfn_x(omfn), gfn_x(gfn) + i);
-+            }
-+        }
-+    }
-+
-+    if ( pod_count )
-+    {
-+        pod_lock(p2m);
-+        p2m->pod.entry_count -= pod_count;
-+        BUG_ON(p2m->pod.entry_count < 0);
-+        pod_unlock(p2m);
-+    }
- 
- out:
-     p2m_unlock(p2m);
-@@ -1314,6 +1365,51 @@ static int set_typed_p2m_entry(struct do
-             return 0;
-         }
-     }
-+
-+    P2M_DEBUG("set %d %lx %lx\n", gfn_p2mt, gfn_l, mfn_x(mfn));
-+    rc = p2m_set_entry(p2m, gfn, mfn, order, gfn_p2mt, access);
-+    if ( unlikely(rc) )
-+    {
-+        gdprintk(XENLOG_ERR, "p2m_set_entry: %#lx:%u -> %d (0x%"PRI_mfn")\n",
-+                 gfn_l, order, rc, mfn_x(mfn));
-+
-+        /*
-+         * The operation may have partially succeeded. For the successful part
-+         * we need to update PoD stats, M2P, and dirty state.
-+         */
-+        if ( order != PAGE_ORDER_4K )
-+        {
-+            unsigned long i;
-+
-+            for ( i = 0; i < (1UL << order); ++i )
-+            {
-+                p2m_type_t t;
-+                mfn_t cmfn = p2m->get_entry(p2m, gfn_add(gfn, i), &t, &a, 0,
-+                                            NULL, NULL);
-+
-+                if ( !mfn_eq(cmfn, mfn_add(mfn, i)) || t != gfn_p2mt ||
-+                     a != access )
-+                    continue;
-+
-+                if ( p2m_is_ram(ot) )
-+                {
-+                    ASSERT(mfn_valid(mfn_add(omfn, i)));
-+                    set_gpfn_from_mfn(mfn_x(omfn) + i, INVALID_M2P_ENTRY);
-+
-+                    ioreq_request_mapcache_invalidate(d);
-+                }
-+#ifdef CONFIG_HVM
-+                else if ( p2m_is_pod(ot) )
-+                {
-+                    pod_lock(p2m);
-+                    BUG_ON(!p2m->pod.entry_count);
-+                    --p2m->pod.entry_count;
-+                    pod_unlock(p2m);
-+                }
-+#endif
-+            }
-+        }
-+    }
-     else if ( p2m_is_ram(ot) )
-     {
-         unsigned long i;
-@@ -1326,12 +1422,6 @@ static int set_typed_p2m_entry(struct do
- 
-         ioreq_request_mapcache_invalidate(d);
-     }
--
--    P2M_DEBUG("set %d %lx %lx\n", gfn_p2mt, gfn_l, mfn_x(mfn));
--    rc = p2m_set_entry(p2m, gfn, mfn, order, gfn_p2mt, access);
--    if ( rc )
--        gdprintk(XENLOG_ERR, "p2m_set_entry: %#lx:%u -> %d (0x%"PRI_mfn")\n",
--                 gfn_l, order, rc, mfn_x(mfn));
- #ifdef CONFIG_HVM
-     else if ( p2m_is_pod(ot) )
-     {

xsa390.patch

@@ -1,46 +0,0 @@
-From: Jan Beulich <jbeulich@suse.com>
-Subject: VT-d: fix reduced page table levels support when sharing tables
-
-domain_pgd_maddr() contains logic to adjust the root address to be put
-in the context entry in case 4-level page tables aren't supported by an
-IOMMU. This logic may not be bypassed when sharing page tables.
-
-This is CVE-2021-28710 / XSA-390.
-
-Fixes: 25ccd093425c ("iommu: remove the share_p2m operation")
-Signed-off-by: Jan Beulich <jbeulich@suse.com>
-Reviewed-by: Kevin Tian <kevin.tian@intel.com>
-
---- a/xen/drivers/passthrough/vtd/iommu.c
-+++ b/xen/drivers/passthrough/vtd/iommu.c
-@@ -340,19 +340,21 @@ static uint64_t domain_pgd_maddr(struct
-     {
-         pagetable_t pgt = p2m_get_pagetable(p2m_get_hostp2m(d));
- 
--        return pagetable_get_paddr(pgt);
-+        pgd_maddr = pagetable_get_paddr(pgt);
-     }
--
--    if ( !hd->arch.vtd.pgd_maddr )
-+    else
-     {
--        /* Ensure we have pagetables allocated down to leaf PTE. */
--        addr_to_dma_page_maddr(d, 0, 1);
--
-         if ( !hd->arch.vtd.pgd_maddr )
--            return 0;
--    }
-+        {
-+            /* Ensure we have pagetables allocated down to leaf PTE. */
-+            addr_to_dma_page_maddr(d, 0, 1);
- 
--    pgd_maddr = hd->arch.vtd.pgd_maddr;
-+            if ( !hd->arch.vtd.pgd_maddr )
-+                return 0;
-+        }
-+
-+        pgd_maddr = hd->arch.vtd.pgd_maddr;
-+    }
- 
-     /* Skip top levels of page tables for 2- and 3-level DRHDs. */
-     for ( agaw = level_to_agaw(4);