All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: xen-devel <xen-devel@lists.xenproject.org>
Cc: xiantao.zhang@intel.com, Donald D Dugger <donald.d.dugger@intel.com>
Subject: [PATCH 2/2] VT-d: extend error report masking workaround to newer chipsets
Date: Mon, 28 Apr 2014 09:01:38 +0100	[thread overview]
Message-ID: <535E2702020000780000CACC@nat28.tlf.novell.com> (raw)
In-Reply-To: <535E254A020000780000CA9A@nat28.tlf.novell.com>

[-- Attachment #1: Type: text/plain, Size: 1966 bytes --]

Add two more PCI IDs to the set that has been taken care of with a
different workaround long before XSA-59, and (for constency with the
newer workarounds) log a message here too.

Also move the function wide comment to the cases it applies to; this
should really have been done by d061d200 ("VT-d: suppress UR signaling
for server chipsets").

This is CVE-2013-3495 / XSA-59.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/vtd/quirks.c
+++ b/xen/drivers/passthrough/vtd/quirks.c
@@ -379,12 +379,6 @@ void me_wifi_quirk(struct domain *domain
     }
 }
 
-/*
- * Mask reporting Intel VT-d faults to IOH core logic:
- *   - Some platform escalates VT-d faults to platform errors 
- *   - This can cause system failure upon non-fatal VT-d faults
- *   - Potential security issue if malicious guest trigger VT-d faults
- */
 void pci_vtd_quirk(const struct pci_dev *pdev)
 {
     int seg = pdev->seg;
@@ -402,10 +396,20 @@ void pci_vtd_quirk(const struct pci_dev 
 
     switch ( pci_conf_read16(seg, bus, dev, func, PCI_DEVICE_ID) )
     {
+    /*
+     * Mask reporting Intel VT-d faults to IOH core logic:
+     *   - Some platform escalates VT-d faults to platform errors.
+     *   - This can cause system failure upon non-fatal VT-d faults.
+     *   - Potential security issue if malicious guest trigger VT-d faults.
+     */
+    case 0x0e28: /* Xeon-E5v2 (IvyBridge) */
     case 0x342e: /* Tylersburg chipset (Nehalem / Westmere systems) */
+    case 0x3728: /* Xeon C5500/C3500 (JasperForest) */
     case 0x3c28: /* Sandybridge */
         val = pci_conf_read32(seg, bus, dev, func, 0x1AC);
         pci_conf_write32(seg, bus, dev, func, 0x1AC, val | (1 << 31));
+        printk(XENLOG_INFO "Masked VT-d error signaling on %04x:%02x:%02x.%u\n",
+               seg, bus, dev, func);
         break;
 
     /* Tylersburg (EP)/Boxboro (MP) chipsets (NHM-EP/EX, WSM-EP/EX) */




[-- Attachment #2: VT-d-mask-error-reporting.patch --]
[-- Type: text/plain, Size: 2026 bytes --]

VT-d: extend error report masking workaround to newer chipsets

Add two more PCI IDs to the set that has been taken care of with a
different workaround long before XSA-59, and (for constency with the
newer workarounds) log a message here too.

Also move the function wide comment to the cases it applies to; this
should really have been done by d061d200 ("VT-d: suppress UR signaling
for server chipsets").

This is CVE-2013-3495 / XSA-59.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/vtd/quirks.c
+++ b/xen/drivers/passthrough/vtd/quirks.c
@@ -379,12 +379,6 @@ void me_wifi_quirk(struct domain *domain
     }
 }
 
-/*
- * Mask reporting Intel VT-d faults to IOH core logic:
- *   - Some platform escalates VT-d faults to platform errors 
- *   - This can cause system failure upon non-fatal VT-d faults
- *   - Potential security issue if malicious guest trigger VT-d faults
- */
 void pci_vtd_quirk(const struct pci_dev *pdev)
 {
     int seg = pdev->seg;
@@ -402,10 +396,20 @@ void pci_vtd_quirk(const struct pci_dev 
 
     switch ( pci_conf_read16(seg, bus, dev, func, PCI_DEVICE_ID) )
     {
+    /*
+     * Mask reporting Intel VT-d faults to IOH core logic:
+     *   - Some platform escalates VT-d faults to platform errors.
+     *   - This can cause system failure upon non-fatal VT-d faults.
+     *   - Potential security issue if malicious guest trigger VT-d faults.
+     */
+    case 0x0e28: /* Xeon-E5v2 (IvyBridge) */
     case 0x342e: /* Tylersburg chipset (Nehalem / Westmere systems) */
+    case 0x3728: /* Xeon C5500/C3500 (JasperForest) */
     case 0x3c28: /* Sandybridge */
         val = pci_conf_read32(seg, bus, dev, func, 0x1AC);
         pci_conf_write32(seg, bus, dev, func, 0x1AC, val | (1 << 31));
+        printk(XENLOG_INFO "Masked VT-d error signaling on %04x:%02x:%02x.%u\n",
+               seg, bus, dev, func);
         break;
 
     /* Tylersburg (EP)/Boxboro (MP) chipsets (NHM-EP/EX, WSM-EP/EX) */

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

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

  parent reply	other threads:[~2014-04-28  8:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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
2014-04-28  8:01 ` Jan Beulich [this message]
2014-04-28  9:34   ` [PATCH 2/2] VT-d: extend error report masking workaround to newer chipsets Andrew Cooper
2014-04-28  9:56     ` Jan Beulich
2014-04-28  9:57       ` Andrew Cooper
2014-05-20  0:47   ` Zhang, Xiantao
2014-05-08  8:07 ` Ping: [PATCH 0/2] VT-d: further XSA-59 workaround adjustments Jan Beulich
2014-05-16  9:30   ` Ping II: " Jan Beulich
     [not found] <A9667DDFB95DB7438FA9D7D576C3D87E0AACE649@SHSMSX104.ccr.corp.intel.com>
2014-05-20 13:39 ` [PATCH 2/2] VT-d: extend error report masking workaround to newer chipsets Zhang, Yang Z

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=535E2702020000780000CACC@nat28.tlf.novell.com \
    --to=jbeulich@suse.com \
    --cc=donald.d.dugger@intel.com \
    --cc=xen-devel@lists.xenproject.org \
    --cc=xiantao.zhang@intel.com \
    /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.