All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xenia Ragiadakou <burzalodowa@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: "Kevin Tian" <kevin.tian@intel.com>,
	"Jan Beulich" <jbeulich@suse.com>, "Paul Durrant" <paul@xen.org>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH v3 5/8] x86/iommu: make code addressing CVE-2011-1898 no VT-d specific
Date: Mon, 16 Jan 2023 09:21:12 +0200	[thread overview]
Message-ID: <f620f8ee-e852-de62-53ef-5cd243e4cc09@gmail.com> (raw)
In-Reply-To: <20230116070431.905594-6-burzalodowa@gmail.com>


On 1/16/23 09:04, Xenia Ragiadakou wrote:
> The variable untrusted_msi indicates whether the system is vulnerable to
> CVE-2011-1898 due to the absence of interrupt remapping  support.
> AMD iommus with interrupt remapping disabled are also exposed.
> Therefore move the definition of the variable 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@gmail.com>
> ---
> 
> Changes in v3:
>    - change untrusted_msi from being VT-d specific to PV specific and
>      update commit log accordingly
>    - remove unnecessary #ifdef guard from its declaration
> 
>   xen/drivers/passthrough/vtd/iommu.c | 3 ---
>   xen/drivers/passthrough/x86/iommu.c | 5 +++++
>   2 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c
> index 62e143125d..dae2426cb9 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
> diff --git a/xen/drivers/passthrough/x86/iommu.c b/xen/drivers/passthrough/x86/iommu.c
> index f671b0f2bb..c5021ea023 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

Here, somehow I missed the part:
diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index dae2426cb9..e97b1fe8cd 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2767,6 +2767,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 +2776,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);

I will fix it in the next version.

-- 
Xenia


  reply	other threads:[~2023-01-16  7:21 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-16  7:04 [PATCH v3 0/8] Make x86 IOMMU driver support configurable Xenia Ragiadakou
2023-01-16  7:04 ` [PATCH v3 1/8] x86/iommu: amd_iommu_perdev_intremap is AMD-Vi specific Xenia Ragiadakou
2023-01-16 16:36   ` Jan Beulich
2023-01-16  7:04 ` [PATCH v3 2/8] x86/iommu: iommu_igfx and iommu_qinval are Intel VT-d specific Xenia Ragiadakou
2023-01-16 16:38   ` Jan Beulich
2023-01-16  7:04 ` [PATCH v3 3/8] x86/iommu: snoop control is allowed only by Intel VT-d Xenia Ragiadakou
2023-01-16 16:39   ` Jan Beulich
2023-01-16  7:04 ` [PATCH v3 4/8] x86/acpi: separate AMD-Vi and VT-d specific functions Xenia Ragiadakou
2023-01-16 16:43   ` Jan Beulich
2023-01-16  7:04 ` [PATCH v3 5/8] x86/iommu: make code addressing CVE-2011-1898 no VT-d specific Xenia Ragiadakou
2023-01-16  7:21   ` Xenia Ragiadakou [this message]
2023-01-16 16:49     ` Jan Beulich
2023-01-16 17:21       ` Xenia Ragiadakou
2023-01-16  7:04 ` [PATCH v3 6/8] x86/iommu: call pi_update_irte through an hvm_function callback Xenia Ragiadakou
2023-01-16  9:35   ` Xenia Ragiadakou
2023-01-16  7:04 ` [PATCH v3 7/8] x86/dpci: move hvm_dpci_isairq_eoi() to generic HVM code Xenia Ragiadakou
2023-01-16  7:04 ` [PATCH v3 8/8] x86/iommu: make AMD-Vi and Intel VT-d support configurable Xenia Ragiadakou

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=f620f8ee-e852-de62-53ef-5cd243e4cc09@gmail.com \
    --to=burzalodowa@gmail.com \
    --cc=jbeulich@suse.com \
    --cc=kevin.tian@intel.com \
    --cc=paul@xen.org \
    --cc=roger.pau@citrix.com \
    --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.