From: "Jan Beulich" <JBeulich@suse.com>
To: xen-devel <xen-devel@lists.xenproject.org>
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Kevin Tian <kevin.tian@intel.com>
Subject: [PATCH][XSA-59] VT-d: suppress UR signaling for further desktop chipsets
Date: Tue, 16 Sep 2014 08:18:36 +0100 [thread overview]
Message-ID: <5418006C02000078000353DA@mail.emea.novell.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1601 bytes --]
This extends commit d6cb14b34f ("VT-d: suppress UR signaling for
desktop chipsets") as per the finally obtained list of affected
chipsets from Intel.
Also pad the IDs we had listed there before to full 4 hex digits.
This is CVE-2013-3495 / XSA-59.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
I already raised the obvious questions connected to the appearance of
Broadwell here: Are its server chipsets affected then too, i.e. does
the server side set of IDs need extension as well? Is the issue going
to be fixed in hardware at some point, or will we need to indefinitely
extend the set of IDs here?
--- a/xen/drivers/passthrough/vtd/quirks.c
+++ b/xen/drivers/passthrough/vtd/quirks.c
@@ -466,10 +466,12 @@ void pci_vtd_quirk(const struct pci_dev
action, seg, bus, dev, func);
break;
- case 0x100: case 0x104: case 0x108: /* Sandybridge */
- case 0x150: case 0x154: case 0x158: /* Ivybridge */
- case 0xa04: /* Haswell ULT */
- case 0xc00: case 0xc04: case 0xc08: /* Haswell */
+ case 0x0040: case 0x0044: case 0x0048: /* Nehalem/Westmere */
+ case 0x0100: case 0x0104: case 0x0108: /* Sandybridge */
+ case 0x0150: case 0x0154: case 0x0158: /* Ivybridge */
+ case 0x0a04: /* Haswell ULT */
+ case 0x0c00: case 0x0c04: case 0x0c08: /* Haswell */
+ case 0x1600: case 0x1604: case 0x1608: /* Broadwell */
bar = pci_conf_read32(seg, bus, dev, func, 0x6c);
bar = (bar << 32) | pci_conf_read32(seg, bus, dev, func, 0x68);
pa = bar & 0x7ffffff000UL; /* bits 12...38 */
[-- Attachment #2: VT-d-mask-UR-more-desktop-chipsets.patch --]
[-- Type: text/plain, Size: 1655 bytes --]
VT-d: suppress UR signaling for further desktop chipsets
This extends commit d6cb14b34f ("VT-d: suppress UR signaling for
desktop chipsets") as per the finally obtained list of affected
chipsets from Intel.
Also pad the IDs we had listed there before to full 4 hex digits.
This is CVE-2013-3495 / XSA-59.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
I already raised the obvious questions connected to the appearance of
Broadwell here: Are its server chipsets affected then too, i.e. does
the server side set of IDs need extension as well? Is the issue going
to be fixed in hardware at some point, or will we need to indefinitely
extend the set of IDs here?
--- a/xen/drivers/passthrough/vtd/quirks.c
+++ b/xen/drivers/passthrough/vtd/quirks.c
@@ -466,10 +466,12 @@ void pci_vtd_quirk(const struct pci_dev
action, seg, bus, dev, func);
break;
- case 0x100: case 0x104: case 0x108: /* Sandybridge */
- case 0x150: case 0x154: case 0x158: /* Ivybridge */
- case 0xa04: /* Haswell ULT */
- case 0xc00: case 0xc04: case 0xc08: /* Haswell */
+ case 0x0040: case 0x0044: case 0x0048: /* Nehalem/Westmere */
+ case 0x0100: case 0x0104: case 0x0108: /* Sandybridge */
+ case 0x0150: case 0x0154: case 0x0158: /* Ivybridge */
+ case 0x0a04: /* Haswell ULT */
+ case 0x0c00: case 0x0c04: case 0x0c08: /* Haswell */
+ case 0x1600: case 0x1604: case 0x1608: /* Broadwell */
bar = pci_conf_read32(seg, bus, dev, func, 0x6c);
bar = (bar << 32) | pci_conf_read32(seg, bus, dev, func, 0x68);
pa = bar & 0x7ffffff000UL; /* bits 12...38 */
[-- Attachment #3: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next reply other threads:[~2014-09-16 7:18 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-16 7:18 Jan Beulich [this message]
2014-09-18 5:28 ` [PATCH][XSA-59] VT-d: suppress UR signaling for further desktop 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=5418006C02000078000353DA@mail.emea.novell.com \
--to=jbeulich@suse.com \
--cc=kevin.tian@intel.com \
--cc=xen-devel@lists.xenproject.org \
--cc=yang.z.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).