From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: [PATCH 2/2] VT-d: extend error report masking workaround to newer chipsets Date: Mon, 28 Apr 2014 09:01:38 +0100 Message-ID: <535E2702020000780000CACC@nat28.tlf.novell.com> References: <535E254A020000780000CA9A@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part9DAF9DF2.1__=" Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WegVU-0002Sf-I3 for xen-devel@lists.xenproject.org; Mon, 28 Apr 2014 08:01:44 +0000 In-Reply-To: <535E254A020000780000CA9A@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel Cc: xiantao.zhang@intel.com, Donald D Dugger List-Id: xen-devel@lists.xenproject.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part9DAF9DF2.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 --- 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 } } =20 -/* - * Mask reporting Intel VT-d faults to IOH core logic: - * - Some platform escalates VT-d faults to platform errors=20 - * - 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 =3D pdev->seg; @@ -402,10 +396,20 @@ void pci_vtd_quirk(const struct pci_dev=20 =20 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 =3D 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; =20 /* Tylersburg (EP)/Boxboro (MP) chipsets (NHM-EP/EX, WSM-EP/EX) */ --=__Part9DAF9DF2.1__= Content-Type: text/plain; name="VT-d-mask-error-reporting.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="VT-d-mask-error-reporting.patch" VT-d: extend error report masking workaround to newer chipsets=0A=0AAdd = two more PCI IDs to the set that has been taken care of with a=0Adifferent = workaround long before XSA-59, and (for constency with the=0Anewer = workarounds) log a message here too.=0A=0AAlso move the function wide = comment to the cases it applies to; this=0Ashould really have been done by = d061d200 ("VT-d: suppress UR signaling=0Afor server chipsets").=0A=0AThis = is CVE-2013-3495 / XSA-59.=0A=0ASigned-off-by: Jan Beulich =0A=0A--- a/xen/drivers/passthrough/vtd/quirks.c=0A+++ b/xen/drivers/pas= sthrough/vtd/quirks.c=0A@@ -379,12 +379,6 @@ void me_wifi_quirk(struct = domain *domain=0A }=0A }=0A =0A-/*=0A- * Mask reporting Intel VT-d = faults to IOH core logic:=0A- * - Some platform escalates VT-d faults to = platform errors =0A- * - This can cause system failure upon non-fatal = VT-d faults=0A- * - Potential security issue if malicious guest trigger = VT-d faults=0A- */=0A void pci_vtd_quirk(const struct pci_dev *pdev)=0A = {=0A int seg =3D pdev->seg;=0A@@ -402,10 +396,20 @@ void pci_vtd_quirk(= const struct pci_dev =0A =0A switch ( pci_conf_read16(seg, bus, dev, = func, PCI_DEVICE_ID) )=0A {=0A+ /*=0A+ * Mask reporting Intel = VT-d faults to IOH core logic:=0A+ * - Some platform escalates VT-d = faults to platform errors.=0A+ * - This can cause system failure = upon non-fatal VT-d faults.=0A+ * - Potential security issue if = malicious guest trigger VT-d faults.=0A+ */=0A+ case 0x0e28: /* = Xeon-E5v2 (IvyBridge) */=0A case 0x342e: /* Tylersburg chipset = (Nehalem / Westmere systems) */=0A+ case 0x3728: /* Xeon C5500/C3500 = (JasperForest) */=0A case 0x3c28: /* Sandybridge */=0A val =3D = pci_conf_read32(seg, bus, dev, func, 0x1AC);=0A pci_conf_write32(se= g, bus, dev, func, 0x1AC, val | (1 << 31));=0A+ printk(XENLOG_INFO = "Masked VT-d error signaling on %04x:%02x:%02x.%u\n",=0A+ = seg, bus, dev, func);=0A break;=0A =0A /* Tylersburg (EP)/Boxbo= ro (MP) chipsets (NHM-EP/EX, WSM-EP/EX) */=0A --=__Part9DAF9DF2.1__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part9DAF9DF2.1__=--