linux-kernel - Re: [PATCH 2/2] arm64: errata: Work around AmpereOne's erratum AC04_CPU

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: <86plhbyafk.fsf@scott-ph-mail.amperecomputing.com>
Date: Wed, 16 Apr 2025 16:05:19 -0700
From: D Scott Phillips <scott@...amperecomputing.com>
To: Oliver Upton <oliver.upton@...ux.dev>
Cc: Marc Zyngier <maz@...nel.org>, Catalin Marinas
 <catalin.marinas@....com>, James Clark <james.clark@...aro.org>, James
 Morse <james.morse@....com>, Joey Gouly <joey.gouly@....com>, Kevin
 Brodsky <kevin.brodsky@....com>, Mark Brown <broonie@...nel.org>, Mark
 Rutland <mark.rutland@....com>, "Rob Herring (Arm)" <robh@...nel.org>,
 Shameer Kolothum <shameerali.kolothum.thodi@...wei.com>, Shiqi Liu
 <shiqiliu@...t.edu.cn>, Will Deacon <will@...nel.org>, Yicong Yang
 <yangyicong@...ilicon.com>, kvmarm@...ts.linux.dev,
 linux-arm-kernel@...ts.infradead.org, open list
 <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] arm64: errata: Work around AmpereOne's erratum
 AC04_CPU_23

Oliver Upton <oliver.upton@...ux.dev> writes:

> On Tue, Apr 15, 2025 at 03:13:43PM -0700, D Scott Phillips wrote:
>> > At least from your erratum description it isn't clear to me that this
>> > eliminates the problem and only narrows the window of opportunity.
>> > Couldn't the implementation speculatively fetch translations with an
>> > unsynchronized HCR up to the ISB? Do we know what translation regimes
>> > are affected by the erratum?
>> 
>> Hi Oliver, I got some clarification from the core folks. The issue
>> affects the data side of the core only, not the instruction side.  I'll
>> update my description to include that.
>> 
>> Speculation after the `msr hcr_el2` couldn't launch a problem
>> translation when the `msr` is followed by an `isb` like this.
>
> Thanks, agree that the subsequent ISB protects against speculative
> behavior relating to the instruction stream. To be absolutely certain,
> there's no risk of, say, a TLB prefetcher pulling in a problematic
> translation in this window? IOW, there's no behavior that meets the ARM
> ARM definition of a Speculative operation that can lead to a corrupted
> translation.

Yes, that's right, it's just translations from load/store instructions,
and the DSB before closes the window where earlier instructions can get
corrupted, and then the ISB after prevents the window for corruption
from later instructions from overlapping with the write to HCR.

> Sorry to hassle about these issues but they're helpful for maintaining
> the workaround in the future. If you can fold all the extra details into
> the patch for v2 that'd be great.

No worries, and sorry to not have the description more clear
originally. I'll include a more complete description in the next
version.