All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "'Jan Beulich (JBeulich@suse.com)'" <JBeulich@suse.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 1/2] VT-d: apply quirks at device setup time rather than only at boot
Date: Tue, 20 May 2014 13:39:36 +0000	[thread overview]
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E0AACE6DC@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0AACE698@SHSMSX104.ccr.corp.intel.com>

> Accessing extended config space may not be possible at boot time, e.g.
> when the memory space used by MMCFG is reserved only via ACPI tables, but
> not in the E820/UEFI memory maps (which we need Dom0 to tell us about).
> Consequently the change here still leaves the issue unaddressed for systems
> where the extended config space remains inaccessible (due to firmware bugs,
> i.e. not properly reserving the address space of those regions).
> 
> With the respective messages now potentially getting logged more than once,
> we ought to consider whether we should issue them only if we in fact were
> required to do any masking (i.e. if the relevant mask bits weren't already set).
> 
> This is CVE-2013-3495 / XSA-59.
> 
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

Acked-by: Yang Zhang <yang.z.zhang@intel.com>

> 
> --- a/xen/drivers/passthrough/vtd/extern.h
> +++ b/xen/drivers/passthrough/vtd/extern.h
> @@ -99,7 +99,7 @@ void platform_quirks_init(void);  void
> vtd_ops_preamble_quirk(struct iommu* iommu);  void
> vtd_ops_postamble_quirk(struct iommu* iommu);  void me_wifi_quirk(struct
> domain *domain, u8 bus, u8 devfn, int map); -void pci_vtd_quirk(struct pci_dev
> *pdev);
> +void pci_vtd_quirk(const struct pci_dev *);
>  int platform_supports_intremap(void);
>  int platform_supports_x2apic(void);
> 
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1483,6 +1483,9 @@ static int domain_context_mapping(
>          break;
>      }
> 
> +    if ( !ret && devfn == pdev->devfn )
> +        pci_vtd_quirk(pdev);
> +
>      return ret;
>  }
> 
> @@ -1922,6 +1925,8 @@ static int intel_iommu_enable_device(str
>      struct acpi_drhd_unit *drhd = acpi_find_matched_drhd_unit(pdev);
>      int ret = drhd ? ats_device(pdev, drhd) : -ENODEV;
> 
> +    pci_vtd_quirk(pdev);
> +
>      if ( ret <= 0 )
>          return ret;
> 
> @@ -1994,12 +1999,7 @@ static int intel_iommu_remove_device(u8
> 
>  static int __hwdom_init setup_hwdom_device(u8 devfn, struct pci_dev *pdev)
> {
> -    int err;
> -
> -    err = domain_context_mapping(pdev->domain, devfn, pdev);
> -    if ( !err && devfn == pdev->devfn )
> -        pci_vtd_quirk(pdev);
> -    return err;
> +    return domain_context_mapping(pdev->domain, devfn, pdev);
>  }
> 
>  void clear_fault_bits(struct iommu *iommu)
> --- a/xen/drivers/passthrough/vtd/quirks.c
> +++ b/xen/drivers/passthrough/vtd/quirks.c
> @@ -385,7 +385,7 @@ void me_wifi_quirk(struct domain *domain
>   *   - This can cause system failure upon non-fatal VT-d faults
>   *   - Potential security issue if malicious guest trigger VT-d faults
>   */
> -void __hwdom_init pci_vtd_quirk(struct pci_dev *pdev)
> +void pci_vtd_quirk(const struct pci_dev *pdev)
>  {
>      int seg = pdev->seg;
>      int bus = pdev->bus;

Best regards
Yang

       reply	other threads:[~2014-05-20 13:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <A9667DDFB95DB7438FA9D7D576C3D87E0AACE698@SHSMSX104.ccr.corp.intel.com>
2014-05-20 13:39 ` Zhang, Yang Z [this message]
2014-04-28  7:54 [PATCH 0/2] VT-d: further XSA-59 workaround adjustments Jan Beulich
2014-04-28  8:01 ` [PATCH 1/2] VT-d: apply quirks at device setup time rather than only at boot Jan Beulich
2014-04-28  9:30   ` Andrew Cooper
2014-04-28  9:55     ` Jan Beulich
2014-04-28 10:01       ` Andrew Cooper
2014-05-20  0:46   ` Zhang, Xiantao

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=A9667DDFB95DB7438FA9D7D576C3D87E0AACE6DC@SHSMSX104.ccr.corp.intel.com \
    --to=yang.z.zhang@intel.com \
    --cc=JBeulich@suse.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.