[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 1/2] VT-d: apply quirks at device setup time rather than only at boot


  • To: Jan Beulich <JBeulich@xxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
  • Date: Tue, 20 May 2014 00:46:46 +0000
  • Accept-language: en-US
  • Cc: "Dugger, Donald D" <donald.d.dugger@xxxxxxxxx>
  • Delivery-date: Tue, 20 May 2014 00:47:16 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: AQHPYrgrZZh4ws9WL06Wwc2I4xqPHJtIxEjA
  • Thread-topic: [PATCH 1/2] VT-d: apply quirks at device setup time rather than only at boot

Thanks, Acked-by: Xiantao Zhang <xiantao.zhang@xxxxxxxxx>
Xiantao.

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Monday, April 28, 2014 4:01 PM
> To: xen-devel
> Cc: Dugger, Donald D; Zhang, Xiantao
> Subject: [PATCH 1/2] VT-d: apply quirks at device setup time rather than only 
> at
> boot
> 
> 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>
> 
> --- 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;
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.