update to xen-4.14.5

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]

.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.14.1.tar.gz
+/xen-4.14.5.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.14.1.tar.gz) = c75cbec82793435f5a7026626ffdb2e9a2166b42d2be4b2f1194240e0312458124f0ebd53eeb02ce7330c22afe402a28a96b32f8af66e41e9416fe94535724c9
+SHA512 (xen-4.14.5.tar.gz) = 7fc1c98b5e135e14a1902786d6cf44304c1c1e9b600195592aa3d12ba937bc307eaae984596c30544519f181d2a02f2c9ad9c94d6b2b6fac2091b54568b0705e

xen.gcc11.fixes.patch

@@ -1,15 +1,3 @@
---- xen-4.14.0/xen/include/crypto/rijndael.h.orig	2020-07-23 16:07:51.000000000 +0100
-+++ xen-4.14.0/xen/include/crypto/rijndael.h	2020-10-24 14:59:34.349318594 +0100
-@@ -52,7 +52,7 @@
- 
- int	rijndaelKeySetupEnc(unsigned int [], const unsigned char [], int);
- int	rijndaelKeySetupDec(unsigned int [], const unsigned char [], int);
--void	rijndaelEncrypt(const unsigned int [], int, const unsigned char [],
--	    unsigned char []);
-+void	rijndaelEncrypt(const unsigned int [], int, const unsigned char [16],
-+	    unsigned char [16]);
- 
- #endif /* __RIJNDAEL_H */
 --- xen-4.14.0/xen/include/crypto/vmac.h.orig	2020-07-23 16:07:51.000000000 +0100
 +++ xen-4.14.0/xen/include/crypto/vmac.h	2020-10-24 15:45:49.246467465 +0100
 @@ -142,7 +142,7 @@
@@ -21,28 +9,6 @@
            unsigned int mbytes,
            vmac_ctx_t *ctx);
  
---- xen-4.14.0/tools/libs/foreignmemory/linux.c.orig	2020-07-23 16:07:51.000000000 +0100
-+++ xen-4.14.0/tools/libs/foreignmemory/linux.c	2020-10-25 21:36:00.982040566 +0000
-@@ -162,7 +162,7 @@
- void *osdep_xenforeignmemory_map(xenforeignmemory_handle *fmem,
-                                  uint32_t dom, void *addr,
-                                  int prot, int flags, size_t num,
--                                 const xen_pfn_t arr[/*num*/], int err[/*num*/])
-+                                 const xen_pfn_t arr[num], int err[num])
- {
-     int fd = fmem->fd;
-     privcmd_mmapbatch_v2_t ioctlx;
---- xen-4.14.0/tools/libs/foreignmemory/minios.c.orig	2020-07-23 16:07:51.000000000 +0100
-+++ xen-4.14.0/tools/libs/foreignmemory/minios.c	2020-10-26 22:36:12.423883688 +0000
-@@ -42,7 +42,7 @@
- void *osdep_xenforeignmemory_map(xenforeignmemory_handle *fmem,
-                                  uint32_t dom, void *addr,
-                                  int prot, int flags, size_t num,
--                                 const xen_pfn_t arr[/*num*/], int err[/*num*/])
-+                                 const xen_pfn_t arr[num], int err[num])
- {
-     unsigned long pt_prot = 0;
-     if (prot & PROT_READ)
 diff --git a/xen/arch/x86/tboot.c b/xen/arch/x86/tboot.c
 index 320e06f..618ae92 100644
 --- a/xen/arch/x86/tboot.c
@@ -56,20 +22,3 @@ index 320e06f..618ae92 100644
  
      /* Look for valid page-aligned address for shared page. */
      if ( !opt_tboot_pa || (opt_tboot_pa & ~PAGE_MASK) )
-diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c
-index 84bb8e0..6ecf5db 100644
---- a/xen/arch/x86/x86_emulate/x86_emulate.c
-+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
-@@ -725,9 +725,9 @@ union vex {
- #define copy_VEX(ptr, vex) ({ \
-     if ( !mode_64bit() ) \
-         (vex).reg |= 8; \
--    (ptr)[0 - PFX_BYTES] = ext < ext_8f08 ? 0xc4 : 0x8f; \
--    (ptr)[1 - PFX_BYTES] = (vex).raw[0]; \
--    (ptr)[2 - PFX_BYTES] = (vex).raw[1]; \
-+    ((volatile uint8_t *)ptr)[0 - PFX_BYTES] = ext < ext_8f08 ? 0xc4 : 0x8f; \
-+    ((volatile uint8_t *)ptr)[1 - PFX_BYTES] = (vex).raw[0]; \
-+    ((volatile uint8_t *)ptr)[2 - PFX_BYTES] = (vex).raw[1]; \
-     container_of((ptr) + 1 - PFX_BYTES, typeof(vex), raw[0]); \
- })
- 

xen.spec

@@ -57,8 +57,8 @@
 
 Summary: Xen is a virtual machine monitor
 Name:    xen
-Version: 4.14.1
-Release: 5%{?dist}
+Version: 4.14.5
+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
@@ -112,14 +112,12 @@ Patch40: xen.drop.brctl.patch
 Patch41: xen.gcc9.fixes.patch
 Patch42: xen.gcc10.fixes.patch
 Patch43: xen.gcc11.fixes.patch
-Patch44: xsa360-4.14.patch
 Patch45: xen.git-7c9f81687ad611515474b1c17afc2f79f19faef5.patch
 Patch46: xen.git-35d2960ae65f28106fdc5c2130f5f08fadca0e4c.patch
 Patch47: xen.git-d6627cf1b63ce57a6a7e2c1800dbc50eed742c32.patch
 Patch48: xen.git-d8099d94dfaa3573bd86ebfc457cbc8f70a3ecda.patch
 Patch49: xen.git-8169f82049efb5b2044b33aa482ba3a136b7804d.patch
-Patch50: xsa363.patch
-Patch51: xsa364.patch
+Patch56: xsa376.patch
 
 
 %if %build_qemutrad
@@ -328,14 +326,12 @@ manage Xen virtual machines.
 %patch41 -p1
 %patch42 -p1
 %patch43 -p1
-%patch44 -p1
 %patch45 -p1
 %patch46 -p1
 %patch47 -p1
 %patch48 -p1
 %patch49 -p1
-%patch50 -p1
-%patch51 -p1
+%patch56 -p1
 
 # qemu-xen-traditional patches
 pushd tools/qemu-xen-traditional
@@ -612,16 +608,21 @@ do_it() {
       if [ ! -d $TARGET ]; then
         mkdir $TARGET
       fi
-      if [ -f $DIR/relocator.mod -a ! -f $TARGET/relocator.mod ]; then
-        cp -p $DIR/relocator.mod $TARGET/relocator.mod
-      fi
-      if [ -f $DIR/multiboot2.mod -a ! -f $TARGET/multiboot2.mod ]; then
-        cp -p $DIR/multiboot2.mod $TARGET/multiboot2.mod
-      fi
+      for m in relocator.mod multiboot2.mod; do
+        if [ -f $DIR/$m ]; then
+          if [ ! -f $TARGET/$m ] || ! cmp -s $DIR/$m $TARGET/$m; then
+            cp -p $DIR/$m $TARGET/$m
+          fi
+        fi
+      done
     fi
 }
 if [ $1 == 1 -a -f /sbin/grub2-mkconfig ]; then
+%if "%dist" <= ".fc33"
   for f in /boot/grub2/grub.cfg /boot/efi/EFI/fedora/grub.cfg; do
+%else
+  for f in /boot/grub2/grub.cfg; do
+%endif
     if [ -f $f ]; then
       /sbin/grub2-mkconfig -o $f
       sed -i -e '/insmod module2/d' $f
@@ -633,17 +634,26 @@ if [ -f /sbin/grub2-mkconfig ]; then
     DIR=/usr/lib/grub/i386-pc
     TARGET=/boot/grub2/i386-pc
     do_it $DIR $TARGET
+    DIR=/usr/lib/grub/x86_64-efi
+    TARGET=/boot/grub2/x86_64-efi
+    do_it $DIR $TARGET
   fi
+%if "%dist" <= ".fc33"
   if [ -f /boot/efi/EFI/fedora/grub.cfg ]; then
     DIR=/usr/lib/grub/x86_64-efi
     TARGET=/boot/efi/EFI/fedora/x86_64-efi
     do_it $DIR $TARGET
   fi
+%endif
 fi
 
 %postun hypervisor
 if [ -f /sbin/grub2-mkconfig ]; then
+%if "%dist" <= ".fc33"
   for f in /boot/grub2/grub.cfg /boot/efi/EFI/fedora/grub.cfg; do
+%else
+  for f in /boot/grub2/grub.cfg; do
+%endif
     if [ -f $f ]; then
       /sbin/grub2-mkconfig -o $f
       sed -i -e '/insmod module2/d' $f
@@ -928,6 +938,87 @@ fi
 %endif
 
 %changelog
+* Fri Apr 15 2022 Michael Young <m.a.young@durham.ac.uk> - 4.14.5-1
+- update to xen-4.14.5
+  remove or adjust patches now included or superceded upstream
+
+* Wed Apr 06 2022 Michael Young <m.a.young@durham.ac.uk> - 4.14.4-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.14.4-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.14.4-1
+- update to xen-4.14.4
+  remove or adjust patches now included or superceded upstream
+
+* Tue Jan 25 2022 Michael Young <m.a.young@durham.ac.uk> - 4.14.3-4
+- 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.14.3-3
+- 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
+	CVE-2021-28708]
+- issues with partially successful P2M updates on x86 [XSA-389,
+	CVE-2021-28705, CVE-2021-28709]
+
+* Wed Oct 06 2021 Michael Young <m.a.young@durham.ac.uk> - 4.14.3-2
+- PCI devices with RMRRs not deassigned correctly [XSA-386, CVE-2021-28702]
+	(#2011248)
+
+* Mon Sep 13 2021 Michael Young <m.a.young@durham.ac.uk> - 4.14.3-1
+- update to xen-4.14.3
+  remove or adjust patches now included or superceded upstream
+
+* Wed Sep 08 2021 Michael Young <m.a.young@durham.ac.uk> - 4.14.2-4
+- Another race in XENMAPSPACE_grant_table handling [XSA-384, CVE-2021-28701]
+	(#2002786)
+- bugfix for XSA-380
+- stop editing grub files in /boot/efi/EFI/fedora on Fedora 34
+
+* Sat Aug 28 2021 Michael Young <m.a.young@durham.ac.uk> - 4.14.2-3
+- IOMMU page mapping issues on x86 [XSA-378, CVE-2021-28694,
+	CVE-2021-28695, CVE-2021-28696] (#1997531) (#1997568)
+	(#1997537)
+- grant table v2 status pages may remain accessible after de-allocation
+	[XSA-379, CVE-2021-28697] (#1997520)
+- long running loops in grant table handling [XSA-380, CVE-2021-28698]
+	(#1997526)
+- inadequate grant-v2 status frames array bounds check [XSA-382,
+	CVE-2021-28699] (#1997523)
+- xen/arm: No memory limit for dom0less domUs [XSA-383, CVE-2021-28700]
+	(#1997527)
+- grub x86_64-efi modules now go into /boot/grub2
+
+* Tue Jun 08 2021 Michael Young <m.a.young@durham.ac.uk> - 4.14.2-2
+- xen/arm: Boot modules are not scrubbed [XSA-372, CVE-2021-28693]
+  (#1970542)
+- inappropriate x86 IOMMU timeout detection / handling
+	[XSA-373, CVE-2021-28692] (#1970540)
+- Speculative Code Store Bypass [XSA-375, CVE-2021-0089, CVE-2021-26313]
+	(#1970531)
+- x86: TSX Async Abort protections not restored after S3
+	[XSA-377, CVE-2021-28690] (#1970546)
+
+* Tue May 04 2021 Michael Young <m.a.young@durham.ac.uk> - 4.14.2-1
+- update to 4.14.2
+  remove or adjust patch content now included or superceded upstream
+- re-copy grub modules if they have changed
+
+* Thu Mar 18 2021 Michael Young <m.a.young@durham.ac.uk> - 4.14.1-7
+- HVM soft-reset crashes toolstack [XSA-368, CVE-2021-28687] (#1940610)
+
 * Tue Feb 16 2021 Michael Young <m.a.young@durham.ac.uk> - 4.14.1-5
 - Linux: display frontend "be-alloc" mode is unsupported (comment only)
 	[XSA-363, CVE-2021-26934] (#1929549)

xsa360-4.14.patch

@@ -1,97 +0,0 @@
-From: Roger Pau Monne <roger.pau@citrix.com>
-Subject: x86/dpci: do not remove pirqs from domain tree on unbind
-
-A fix for a previous issue removed the pirqs from the domain tree when
-they are unbound in order to prevent shared pirqs from triggering a
-BUG_ON in __pirq_guest_unbind if they are unbound multiple times. That
-caused free_domain_pirqs to no longer unmap the pirqs because they
-are gone from the domain pirq tree, thus leaving stale unbound pirqs
-after domain destruction if the domain had mapped dpci pirqs after
-shutdown.
-
-Take a different approach to fix the original issue, instead of
-removing the pirq from d->pirq_tree clear the flags of the dpci pirq
-struct to signal that the pirq is now unbound. This prevents calling
-pirq_guest_unbind multiple times for the same pirq without having to
-remove it from the domain pirq tree.
-
-This is XSA-360.
-
-Fixes: 5b58dad089 ('x86/pass-through: avoid double IRQ unbind during domain cleanup')
-Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
-Reviewed-by: Jan Beulich <jbeulich@suse.com>
-
---- a/xen/arch/x86/irq.c
-+++ b/xen/arch/x86/irq.c
-@@ -1331,7 +1331,7 @@ void (pirq_cleanup_check)(struct pirq *p
-     }
- 
-     if ( radix_tree_delete(&d->pirq_tree, pirq->pirq) != pirq )
--        BUG_ON(!d->is_dying);
-+        BUG();
- }
- 
- /* Flush all ready EOIs from the top of this CPU's pending-EOI stack. */
---- a/xen/drivers/passthrough/pci.c
-+++ b/xen/drivers/passthrough/pci.c
-@@ -862,6 +862,10 @@ static int pci_clean_dpci_irq(struct dom
- {
-     struct dev_intx_gsi_link *digl, *tmp;
- 
-+    if ( !pirq_dpci->flags )
-+        /* Already processed. */
-+        return 0;
-+
-     pirq_guest_unbind(d, dpci_pirq(pirq_dpci));
- 
-     if ( pt_irq_need_timer(pirq_dpci->flags) )
-@@ -872,15 +876,10 @@ static int pci_clean_dpci_irq(struct dom
-         list_del(&digl->list);
-         xfree(digl);
-     }
-+    /* Note the pirq is now unbound. */
-+    pirq_dpci->flags = 0;
- 
--    radix_tree_delete(&d->pirq_tree, dpci_pirq(pirq_dpci)->pirq);
--
--    if ( !pt_pirq_softirq_active(pirq_dpci) )
--        return 0;
--
--    domain_get_irq_dpci(d)->pending_pirq_dpci = pirq_dpci;
--
--    return -ERESTART;
-+    return pt_pirq_softirq_active(pirq_dpci) ? -ERESTART : 0;
- }
- 
- static int pci_clean_dpci_irqs(struct domain *d)
-@@ -897,18 +896,8 @@ static int pci_clean_dpci_irqs(struct do
-     hvm_irq_dpci = domain_get_irq_dpci(d);
-     if ( hvm_irq_dpci != NULL )
-     {
--        int ret = 0;
--
--        if ( hvm_irq_dpci->pending_pirq_dpci )
--        {
--            if ( pt_pirq_softirq_active(hvm_irq_dpci->pending_pirq_dpci) )
--                 ret = -ERESTART;
--            else
--                 hvm_irq_dpci->pending_pirq_dpci = NULL;
--        }
-+        int ret = pt_pirq_iterate(d, pci_clean_dpci_irq, NULL);
- 
--        if ( !ret )
--            ret = pt_pirq_iterate(d, pci_clean_dpci_irq, NULL);
-         if ( ret )
-         {
-             spin_unlock(&d->event_lock);
---- a/xen/include/asm-x86/hvm/irq.h
-+++ b/xen/include/asm-x86/hvm/irq.h
-@@ -160,8 +160,6 @@ struct hvm_irq_dpci {
-     DECLARE_BITMAP(isairq_map, NR_ISAIRQS);
-     /* Record of mapped Links */
-     uint8_t link_cnt[NR_LINK];
--    /* Clean up: Entry with a softirq invocation pending / in progress. */
--    struct hvm_pirq_dpci *pending_pirq_dpci;
- };
- 
- /* Machine IRQ to guest device/intx mapping. */

xsa363.patch

@@ -1,22 +0,0 @@
-From: Jan Beulich <jbeulich@suse.com>
-Subject: SUPPORT.md: PV display frontend is unsupported in "backend allocation" mode
-
-This wasn't meant to be supported, but wasn't stated this way.
-
-This is XSA-363.
-
-Reported-by: Jan Belich <jbeulich@suse.com>
-Signed-off-by: Jan Beulich <jbeulich@suse.com>
-
---- a/SUPPORT.md
-+++ b/SUPPORT.md
-@@ -414,7 +414,8 @@ Guest-side driver capable of speaking th
- 
- Guest-side driver capable of speaking the Xen PV display protocol
- 
--    Status, Linux: Supported
-+    Status, Linux: Supported (outside of "backend allocation" mode)
-+    Status, Linux: Experimental (in "backend allocation" mode)
- 
- ### PV Console (frontend)
- 

xsa364.patch

@@ -1,69 +0,0 @@
-From dadb5b4b21c904ce59024c686eb1c55be8f46c52 Mon Sep 17 00:00:00 2001
-From: Julien Grall <jgrall@amazon.com>
-Date: Thu, 21 Jan 2021 10:16:08 +0000
-Subject: [PATCH] xen/page_alloc: Only flush the page to RAM once we know they
- are scrubbed
-
-At the moment, each page are flushed to RAM just after the allocator
-found some free pages. However, this is happening before check if the
-page was scrubbed.
-
-As a consequence, on Arm, a guest may be able to access the old content
-of the scrubbed pages if it has cache disabled (default at boot) and
-the content didn't reach the Point of Coherency.
-
-The flush is now moved after we know the content of the page will not
-change. This also has the benefit to reduce the amount of work happening
-with the heap_lock held.
-
-This is XSA-364.
-
-Fixes: 307c3be3ccb2 ("mm: Don't scrub pages while holding heap lock in alloc_heap_pages()")
-Signed-off-by: Julien Grall <jgrall@amazon.com>
-Reviewed-by: Jan Beulich <jbeulich@suse.com>
----
- xen/common/page_alloc.c | 14 +++++++++-----
- 1 file changed, 9 insertions(+), 5 deletions(-)
-
-diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
-index 02ac1fa613e7..1744e6faa5c4 100644
---- a/xen/common/page_alloc.c
-+++ b/xen/common/page_alloc.c
-@@ -924,6 +924,7 @@ static struct page_info *alloc_heap_pages(
-     bool need_tlbflush = false;
-     uint32_t tlbflush_timestamp = 0;
-     unsigned int dirty_cnt = 0;
-+    mfn_t mfn;
- 
-     /* Make sure there are enough bits in memflags for nodeID. */
-     BUILD_BUG_ON((_MEMF_bits - _MEMF_node) < (8 * sizeof(nodeid_t)));
-@@ -1022,11 +1023,6 @@ static struct page_info *alloc_heap_pages(
-         pg[i].u.inuse.type_info = 0;
-         page_set_owner(&pg[i], NULL);
- 
--        /* Ensure cache and RAM are consistent for platforms where the
--         * guest can control its own visibility of/through the cache.
--         */
--        flush_page_to_ram(mfn_x(page_to_mfn(&pg[i])),
--                          !(memflags & MEMF_no_icache_flush));
-     }
- 
-     spin_unlock(&heap_lock);
-@@ -1062,6 +1058,14 @@ static struct page_info *alloc_heap_pages(
-     if ( need_tlbflush )
-         filtered_flush_tlb_mask(tlbflush_timestamp);
- 
-+    /*
-+     * Ensure cache and RAM are consistent for platforms where the guest
-+     * can control its own visibility of/through the cache.
-+     */
-+    mfn = page_to_mfn(pg);
-+    for ( i = 0; i < (1U << order); i++ )
-+        flush_page_to_ram(mfn_x(mfn) + i, !(memflags & MEMF_no_icache_flush));
-+
-     return pg;
- }
- 
--- 
-2.17.1
-

xsa376.patch

@@ -0,0 +1,144 @@
+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,19 +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
++    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
+