linux-kernel - Re: [PATCH v3 2/4] PCI: brcmstb: Add ACPI config space quirk

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 5 Oct 2021 19:07:36 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Jeremy Linton <jeremy.linton@....com>,
        Pali Rohár <pali@...nel.org>
Cc:     Bjorn Helgaas <helgaas@...nel.org>, linux-pci@...r.kernel.org,
        lorenzo.pieralisi@....com, nsaenz@...nel.org, bhelgaas@...gle.com,
        rjw@...ysocki.net, lenb@...nel.org, robh@...nel.org, kw@...ux.com,
        f.fainelli@...il.com, bcm-kernel-feedback-list@...adcom.com,
        linux-acpi@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-rpi-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/4] PCI: brcmstb: Add ACPI config space quirk



On 10/5/2021 3:25 PM, Jeremy Linton wrote:
> Hi,
> 
> On 10/5/21 2:43 PM, Pali Rohár wrote:
>> Hello!
>>
>> On Tuesday 05 October 2021 10:57:18 Jeremy Linton wrote:
>>> Hi,
>>>
>>> On 10/5/21 10:32 AM, Bjorn Helgaas wrote:
>>>> On Thu, Aug 26, 2021 at 02:15:55AM -0500, Jeremy Linton wrote:
>>>>> Additionally, some basic bus/device filtering exist to avoid sending
>>>>> config transactions to invalid devices on the RP's primary or
>>>>> secondary bus. A basic link check is also made to assure that
>>>>> something is operational on the secondary side before probing the
>>>>> remainder of the config space. If either of these constraints are
>>>>> violated and a config operation is lost in the ether because an EP
>>>>> doesn't respond an unrecoverable SERROR is raised.
>>>>
>>>> It's not "lost"; I assume the root port raises an error because it
>>>> can't send a transaction over a link that is down.
>>>
>>> The problem is AFAIK because the root port doesn't do that.
>>
>> Interesting! Does it mean that PCIe Root Complex / Host Bridge (which I
>> guess contains also logic for Root Port) does not signal transaction
>> failure for config requests? Or it is just your opinion? Because I'm
>> dealing with similar issues and I'm trying to find a way how to detect
>> if some PCIe IP signal transaction error via AXI SLVERR response OR it
>> just does not send any response back. So if you know some way how to
>> check which one it is, I would like to know it too.
> 
> This is my _opinion_ based on what I've heard of some other IP 
> integration issues, and what i've seen poking at this one from the 
> perspective of a SW guy rather than a HW guy. So, basically worthless. 
> But, you should consider that most of these cores/interconnects aren't 
> aware of PCIe completion semantics so its the root ports responsibility 
> to say, gracefully translate a non-posted write that doesn't have a 
> completion for the interconnects its attached to, rather than tripping 
> something generic like a SLVERR.
> 
> Anyway, for this I would poke around the pile of exception registers, 
> with your specific processors manual handy because a lot of them are 
> implementation defined.

I should be able to get you an answer in the new few days whether 
configuration space requests also generate an error towards the ARM CPU, 
since memory space requests most definitively do.
-- 
Florian