linux-kernel - Re: [PATCH 08/10] coresight: trbe: Workaround TRBE errat overwrite in FILL mode

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: <e7241294-d7a3-2286-0bcd-a0cdbec77ffc@arm.com>
Date:   Tue, 7 Sep 2021 10:18:57 +0100
From:   Suzuki K Poulose <suzuki.poulose@....com>
To:     Linu Cherian <linuc.decode@...il.com>
Cc:     linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Mark Rutland <mark.rutland@....com>, maz@...nel.org,
        Anshuman Khandual <anshuman.khandual@....com>,
        catalin.marinas@....com, Coresight ML <coresight@...ts.linaro.org>,
        linux-kernel@...r.kernel.org, james.morse@....com,
        Will Deacon <will@...nel.org>,
        Mike Leach <mike.leach@...aro.org>
Subject: Re: [PATCH 08/10] coresight: trbe: Workaround TRBE errat overwrite in
 FILL mode

Hi Linu

On 06/08/2021 17:09, Linu Cherian wrote:
> Hi Suzuki,
> 
> On Wed, Jul 28, 2021 at 7:23 PM Suzuki K Poulose <suzuki.poulose@....com> wrote:
>>
>> ARM Neoverse-N2 (#2139208) and Cortex-A710(##2119858) suffers from
>> an erratum, which when triggered, might cause the TRBE to overwrite
>> the trace data already collected in FILL mode, in the event of a WRAP.
>> i.e, the TRBE doesn't stop writing the data, instead wraps to the base
>> and could write upto 3 cache line size worth trace. Thus, this could
>> corrupt the trace at the "BASE" pointer.
>>
>> The workaround is to program the write pointer 256bytes from the
>> base, such that if the erratum is triggered, it doesn't overwrite
>> the trace data that was captured. This skipped region could be
>> padded with ignore packets at the end of the session, so that
>> the decoder sees a continuous buffer with some padding at the
>> beginning.
> 
> Just trying to understand,
> Is there a possibility that lost data results in partial trace packets
> towards the end of the buffer ? Or its always guaranteed that
> trace packet end is always aligned with buffer end/limit ?
> Thinking of a case when formatting is disabled.

Yes, trace could be partial towards the end with TRBE in the FILL mode.
The TRBE doesn't add any formatting and is thus raw ETE trace which
doesn't have any alignment requirements. This the case even without
the work around.

Suzuki