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

[Xen-devel] XSA-59


For XSA-59, I list some questions (coming from your patches and emails) and 
consult Intel inside from different groups.

Below are the questions and replies (Q2 still not got answer):
Q1: is the PCI IDs list (0x3400 ...) of root port a complete list? Jan got it 
from a disclosure that Intel made to him meanwhile well over-two-years-ago --> 
Any update about the list?
[Asit]: There is not update to this list. This was provided in 2011 and 
included the Ids prior to being fixed.

Q2: is the PCI IDs list (0x100 ...) of host bridge a complete list? it comes 
from Yuriy but Jan need double confirm 'a complete list'.

Q3: the "...  without AER capability?" warning triggers on Jan's systems --> is 
it an issue? or, how to handle it properly?
[Asit] BIOS can have option to not expose AER capability. It will be good to 
check the BIOS setup options. The error reporting should be masked so not 
action needed.
[Yuriy] I expanded the answer to Q3 vs. what's in the attached email after we 
found out that when root port is operating in DMI mode, AER ext. capability is 
not in the chain of ext. capability headers. Please use this one instead.
Answer to Q3:
On Romley system (DID 0x3c00 ... 0x3c0b), for Host bridge BDF=00:00.0, when the 
root port is operating as DMI, AER extended capability is defined in VSHDR 
(Vendor Specific Header) configuration register (offset 0x148). It should have 
value 0x0004.
After pci_find_ext_capability, if it didn't find AER capability, for 
BDF=00:00.0 the patch would need to check if VSHDR register has value 0x0004 in 
bits [15:0].
Below I've provided example fix for this case:
    case 0x3c00 ... 0x3c0b:
        pos = pci_find_ext_capability(seg, bus, pdev->devfn,
        if ( !pos )
            if ( 0 == bus && 0 == pdev->devfn )
                dmi_aer_cap_id = pci_conf_read16(seg, 0, 0, 0, 0x148) // DMI 
Specific AER Capability ID
                if ( 0x0004 != dmi_aer_cap_id )
                    printk(XENLOG_WARNING "%04x:%02x:%02x.%u without AER 
capability?\n", seg, bus, dev, func);
                printk(XENLOG_WARNING "%04x:%02x:%02x.%u without AER 
capability?\n", seg, bus, dev, func);

Q4: the patches have no way of handling future chipsets (yet we also have no 
indication that future chipsets would not exhibit the same bad behavior) --> 
[Jinsong] IMHO handle future chipset case by case.

Q5: please clarify whether masking the reporting of unsupported requests is 
really an appropriate thing to do: After all, this masks not only maliciously 
created instances of them, but also any ones possibly resulting from 
malfunctioning hardware.
[Yuriy] Most of the client systems don't have SERR enabled (not recommended 
configuration). For server systems, I don't know the answer to this question as 
our team didn't work on the issue and workaround for it when it was defined. 
You'd need to ask Rajesh.

BTW, some other infromation from Yuriy:
1. The workaround is only applicable to the host bridge device 00:00.0 (DMIBAR 
does not exist for other devices). The patch is written generically for any 
PCIe device/bridge.
2. The workaround is only needed when SERR is enabled. As there will be only a 
fraction of client systems with SERR enabled, it might be worthwhile to only 
apply it when SERRE is 1.
   val = pci_conf_read16(seg, bus, dev, func, PCI_COMMAND);
   if ( val & PCI_COMMAND_SERR )
     apply this workaround

Thank you all,
--- Begin Message ---
Patches are attached.


> > Please clarify that aspect as well as confirm that the used list of

> > PCI IDs is complete regarding all your chipsets affected by the issue

> > (or provide a list of necessary additions).

The list contains all device IDs we've confirmed observing this behavior, both 
server and client.

The workaround in patch "VT-d-mask-UR-host-bridge.patch" is only needed when 
SERR is enabled while majority of client systems shouldn't have SERR enabled 
(not recommended configuration).

Might be worth only applying workaround when SERRE is 1.

   val = pci_conf_read16(seg, bus, dev, func, PCI_COMMAND);

   if ( val & PCI_COMMAND_SERR )

     apply this workaround

> Additionally, I discovered an issue needing dealing with on my Romley

> system. The patches result in


> (XEN) 0000:00:00.0 without AER capability?

> (XEN) Masked UR signaling on 0000:00:01.0

> (XEN) Masked UR signaling on 0000:00:01.1

> (XEN) Masked UR signaling on 0000:00:02.0

> (XEN) Masked UR signaling on 0000:00:02.2

> (XEN) Masked UR signaling on 0000:00:03.0

> (XEN) Masked UR signaling on 0000:00:03.2

> (XEN) Masked UR signaling on 0000:80:00.0

> (XEN) Masked UR signaling on 0000:80:01.0

> (XEN) Masked UR signaling on 0000:80:02.0

> (XEN) Masked UR signaling on 0000:80:02.2

> (XEN) Masked UR signaling on 0000:80:03.0

> (XEN) Masked UR signaling on 0000:80:03.2


> and obviously the first of these messages is of concern. The device in

> question is


> 00:00.0 Host bridge [0600]: Intel Corporation Sandy Bridge DMI2

> [8086:3c00] (rev 07)


> i.e. falling into the group of PCI IDs needing to be handled on a PCIe

> root port basis (but calls itself a host bridge). Can anyone shed light

> on why this doesn't have the expected AER capability, and - perhaps

> connected - why it's not a root port? Should we perhaps filter out host

> bridges here? Or was the device ID listed together with the other valid

> ones in error?

On Romley system (DID 0x3c00 ... 0x3c0b), Host bridge (DMI root port 
BDF=00:00.0) when operated in DMI mode has value 0x0004 of extended capability 
ID which is Intel specific ID for AER.

    case 0x3c00 ... 0x3c0b:

        pos = pci_find_ext_capability(seg, bus, pdev->devfn,


pci_find_ext_capability in the patch should check for either 0x0001 or 0x0004 
value of PCI_EXT_CAP before applying workaround.

From: Auld, Will
Sent: Friday, November 15, 2013 10:21 AM
To: Sankaran, Rajesh; Monroe, Bruce; Dugger, Donald D; Bulygin, Yuriy
Cc: Auld, Will
Subject: Outstanding Xen Security issue


Don Dugger, Bruce Monroe, Yuriy Bulygin, Will Auld

Two patches for client system one for Server. Do these cover all the needed 
systems? Yes for shipping client systems, (Broadwell will need it as well). 
Server patch is OK but has a bug.

Yuriy will send all three patches with details server patch bug along with the 
higher level details for Don to communicate to SuSE. Yuriy will send this to 
Don by Monday morning 8AM Pacific.

Thanks everyone,


Attachment: VT-d-mask-UR-root-port.patch
Description: VT-d-mask-UR-root-port.patch

Attachment: VT-d-mask-UR-host-bridge.patch
Description: VT-d-mask-UR-host-bridge.patch

Attachment: pt-suppress-SERR.patch
Description: pt-suppress-SERR.patch

--- End Message ---
Xen-devel mailing list



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