[xen master] x86/iommu: make code addressing CVE-2011-1898 no VT-d specific

[patchbot@xxxxxxx]

commit 9cf1318a32bca00d024fc4ff64f7c317bda56b5d
Author:     Xenia Ragiadakou <burzalodowa@xxxxxxxxx>
AuthorDate: Mon Feb 13 16:27:39 2023 +0100
Commit:     Jan Beulich <jbeulich@xxxxxxxx>
CommitDate: Mon Feb 13 16:27:39 2023 +0100

    x86/iommu: make code addressing CVE-2011-1898 no VT-d specific
    
    The variable untrusted_msi indicates whether the system is vulnerable to
    CVE-2011-1898 due to the absence of interrupt remapping support.
    Although AMD iommus with interrupt remapping disabled are also affected,
    this case is not handled yet. Given that the issue is not VT-d specific,
    and to accommodate future use of the flag for covering also the AMD iommu
    case, move the definition of the flag out of the VT-d specific code to the
    common x86 iommu code.
    
    Also, since the current implementation assumes that only PV guests are prone
    to this attack, take the opportunity to define untrusted_msi only when PV is
    enabled.
    
    No functional change intended.
    
    Signed-off-by: Xenia Ragiadakou <burzalodowa@xxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
---
 xen/drivers/passthrough/vtd/iommu.c | 5 ++---
 xen/drivers/passthrough/x86/iommu.c | 5 +++++
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index a9f4f28ad6..130a159cde 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -54,9 +54,6 @@
                                  ? dom_iommu(d)->arch.vtd.pgd_maddr \
                                  : (pdev)->arch.vtd.pgd_maddr)
 
-/* Possible unfiltered LAPIC/MSI messages from untrusted sources? */
-bool __read_mostly untrusted_msi;
-
 bool __read_mostly iommu_igfx = true;
 bool __read_mostly iommu_qinval = true;
 #ifndef iommu_snoop
@@ -2767,6 +2764,7 @@ static int cf_check reassign_device_ownership(
         if ( !has_arch_pdevs(target) )
             vmx_pi_hooks_assign(target);
 
+#ifdef CONFIG_PV
         /*
          * Devices assigned to untrusted domains (here assumed to be any domU)
          * can attempt to send arbitrary LAPIC/MSI messages. We are unprotected
@@ -2775,6 +2773,7 @@ static int cf_check reassign_device_ownership(
         if ( !iommu_intremap && !is_hardware_domain(target) &&
              !is_system_domain(target) )
             untrusted_msi = true;
+#endif
 
         ret = domain_context_mapping(target, devfn, pdev);
 
diff --git a/xen/drivers/passthrough/x86/iommu.c 
b/xen/drivers/passthrough/x86/iommu.c
index 5a8b28a4ca..9c868db63b 100644
--- a/xen/drivers/passthrough/x86/iommu.c
+++ b/xen/drivers/passthrough/x86/iommu.c
@@ -36,6 +36,11 @@ bool __initdata iommu_superpages = true;
 
 enum iommu_intremap __read_mostly iommu_intremap = iommu_intremap_full;
 
+#ifdef CONFIG_PV
+/* Possible unfiltered LAPIC/MSI messages from untrusted sources? */
+bool __read_mostly untrusted_msi;
+#endif
+
 #ifndef iommu_intpost
 /*
  * In the current implementation of VT-d posted interrupts, in some extreme
--
generated by git-patchbot for /home/xen/git/xen.git#master