linux-kernel - Re: [PATCH 10/10] arm64: errata: Add workaround for TSB flush failures

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: <32f719c8f9f61b244b3fc29137f76a19@kernel.org>
Date:   Mon, 02 Aug 2021 10:35:12 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Anshuman Khandual <anshuman.khandual@....com>
Cc:     Suzuki K Poulose <suzuki.poulose@....com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        coresight@...ts.linaro.org, will@...nel.org,
        catalin.marinas@....com, james.morse@....com,
        mathieu.poirier@...aro.org, mike.leach@...aro.org,
        leo.yan@...aro.org, mark.rutland@....com
Subject: Re: [PATCH 10/10] arm64: errata: Add workaround for TSB flush
 failures

On 2021-08-02 10:12, Anshuman Khandual wrote:
> On 7/29/21 4:11 PM, Suzuki K Poulose wrote:
>> On 29/07/2021 10:55, Marc Zyngier wrote:
>>> On Wed, 28 Jul 2021 14:52:17 +0100,
>>> Suzuki K Poulose <suzuki.poulose@....com>

[...]

>>>> +            __tsb_csync();                        \
>>>> +            __tsb_csync();                        \
>>>> +        } else {                            \
>>>> +            __tsb_csync();                        \
>>>> +        }                                \
>>> 
>>> nit: You could keep one unconditional __tsb_csync().
>> 
>> I thought about that, I was worried if the CPU expects them back to 
>> back
>> without any other instructions in between them. Thinking about it a 
>> bit
>> more, it doesn't look like that is the case. I will confirm this and
>> change it accordingly.
> But its a very subtle change which might be difficult to debug and 
> blame
> later on, if indeed both the instructions need to be back to back. 
> Seems
> like just better to leave this unchanged.

Is that an actual requirement? Sounds like you want to find out
from the errata document.

And if they actually need to be back to back, what ensures that
this is always called with interrupt disabled?

You would also need to have them in the same asm block to avoid
the compiler reordering stuff.

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