linux-kernel - Re: [PATCH v3] PCI: aardvark: Use LTSSM state to build link training flag

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]

Message-ID: <971be151d24312cc533989a64bd454b4@www.loen.fr>
Date:   Mon, 14 Oct 2019 15:18:28 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Remi Pommarel <repk@...plefau.lt>
Cc:     Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Andrew Murray <andrew.murray@....com>,
        Ellie Reeves <ellierevves@...il.com>,
        <linux-pci@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        Bjorn Helgaas <helgaas@...nel.org>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v3] PCI: aardvark: Use LTSSM state to build link  training flag

On 2019-10-14 15:00, Remi Pommarel wrote:
> On Mon, Oct 14, 2019 at 02:45:34PM +0100, Marc Zyngier wrote:
>> Hi Remi,
>>
>> On 2019-10-14 14:06, Remi Pommarel wrote:
>> > Hi Lorenzo, Marc,

[...]

>> > Sure, I think this could be considered a fix for the following 
>> commit :
>> > Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI
>> > bridge config space")
>> >
>> > Moreover, Marc, I am also a bit supprised that you did not have to 
>> use
>> > [1] to even be able to boot.
>>
>> No, I don't have that one, and yet the system boots fine (although 
>> PCI
>> doesn't get much use on this box). I guess I'm lucky...
>>
>> > Also if you want to be completely immune to this kind of SError 
>> (that
>> > could theoretically happen if the link goes down for other reasons 
>> than
>> > being retrained) you would have to use mainline ATF along with 
>> [2]. But
>> > the chances to hit that are low (could only happen in case of link
>> > errors).
>>
>> Now you've got me worried. Can you point me to that ATF patch? I'm 
>> quite
>> curious as to how you recover from an SError on a v8.0 CPU given 
>> that it
>> has no syndrome information and may as well signal "CPU on fire!"...
>>
>
> The patch is at [1]. Please note that this is done quite similarly 
> for
> rcar.
>
> [1] 
> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1541

That patch, without any other information, looks quite flaky. Unless 
there
is a strong guarantee that ESR_EL3.ISS==2 only when the PCIe controller
goes wrong, it looks like this only papers over the issue...

That's pretty much independent from the patch at hand in this thread, 
but
I certainly wouldn't trust this ATF patch without some more information
about how the fault is reported to the CPU.

         M.
-- 
Jazz is not dead. It just smells funny...