linux-kernel - Re: [PATCH v3] PCI: Workaround wrong flags completions for IDT switch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAE9FiQU_Hfsn-_tJSQ2NbqMV-rtaiFsX1FWfe_fADbd8TnKhBA@mail.gmail.com>
Date:   Tue, 13 Jun 2017 10:00:33 -0700
From:   Yinghai Lu <yinghai@...nel.org>
To:     Bjorn Helgaas <helgaas@...nel.org>
Cc:     Bjorn Helgaas <bhelgaas@...gle.com>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        James Puthukattukaran <james.puthukattukaran@...cle.com>
Subject: Re: [PATCH v3] PCI: Workaround wrong flags completions for IDT switch

On Mon, Jun 12, 2017 at 2:48 PM, Bjorn Helgaas <helgaas@...nel.org> wrote:
> On Fri, Jun 09, 2017 at 04:16:17PM -0700, Yinghai Lu wrote:
>> From: James Puthukattukaran <james.puthukattukaran@...cle.com>
>>
>> The IDT switch incorrectly flags an ACS source violation on a read config
>> request to an end point device on the completion (IDT 89H32H8G3-YC,
>> errata #36) even though the PCI Express spec states that completions are
>> never affected by ACS source violation (PCI Spec 3.1, Section 6.12.1.1).
>
> Can you include a URL where this erratum is published?  If not, can
> you include the actual erratum text here?

Ok.

>
> Have you considered ways to make this patch apply only to the affected
> IDT switches?  Currently it applies to *all* devices.

But we need to apply that workaround before we know vendorid/deviceid
under that root port or downstream port.

>
> The purpose of the pci_bus_read_dev_vendor_id() path is to support the
> Configuration Request Retry Status feature (see PCIe r3.1, sec 2.3.2),
> which works by special handling of config reads of the Vendor ID after
> a reset.  Normally, that Vendor ID read would be the first access to
> a device when we enumerate it.
>
> This patch adds config reads and writes of the ACS capability *before*
> the Vendor ID read.  At that point we don't even know whether the
> device exists.  If it doesn't exist, pci_find_ext_capability() would
> read 0xffffffff data, and it probably fails reasonably gracefully.
>
> But if the device *does* exist, I think this patch breaks the CRS
> Software Visibility feature.  Without this patch, we try to read
> Vendor ID, and the device may return a CRS Completion Status.  If CRS
> visibility is enabled, the root complex may complete the request by
> returning 0x0001 for the Vendor ID, in which case we sleep and try
> again later.
>
> With this patch, we first try to read the ACS capability.  If the
> device returns a CRS Completion Status, the root complex is required
> to reissue the config request.  This is the required behavior
> regardless of whether CRS Software Visibility is enabled, so I think
> this effectively disables that feature.

The workaround (acs reading etc) is applied to root port or downstream port.
and pci_bus_read_dev_vendor_id() is for reading vendorid of device
under that root port or downstream port.

Thanks

Yinghai