linux-kernel - Re: [PATCH] arm64: errata: Add Ampere 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 for Android: free password hash cracker in your pocket

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

Message-ID: <Z5lD8HwyQF7IQrEv@linux.dev>
Date: Tue, 28 Jan 2025 12:54:26 -0800
From: Oliver Upton <oliver.upton@...ux.dev>
To: Marc Zyngier <maz@...nel.org>
Cc: Zaid Alali <zaidal@...amperecomputing.com>, catalin.marinas@....com,
	will@...nel.org, puranjay@...nel.org, broonie@...nel.org,
	mbenes@...e.cz, mark.rutland@....com, ruanjinjie@...wei.com,
	robh@...nel.org, anshuman.khandual@....com, james.morse@....com,
	shiqiliu@...t.edu.cn, eahariha@...ux.microsoft.com,
	scott@...amperecomputing.com, joey.gouly@....com, ardb@...nel.org,
	yangyicong@...ilicon.com, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64: errata: Add Ampere erratum AC04_CPU_50 workaround
 alternative

On Tue, Jan 28, 2025 at 08:34:47AM +0000, Marc Zyngier wrote:
> > +config AMPERE_ERRATUM_AC03_CPU_50
> > +	bool "AmpereOne: AC03_CPU_50: Certain checks for ICC_PMR_EL1 that expects the value 0xf0 may read 0xf8 instead"
> > +	default y
> > +	help
> > +	  This option adds an alternative code sequence to work around Ampere
> > +	  erratum AC03_CPU_50 on AmpereOne and Ampere1A.
> > +
> > +	  Due to AC03_CPU_50, when ICC_PMR_EL1 should have a value of 0xf0 a
> > +	  direct read of the register will return a value of 0xf8. An incorrect
> > +	  value from a direct read can only happen with the value 0xf0.
> > +
> > +	  The workaround for the erratum will do logical AND 0xf0 to the
> > +	  value read from ICC_PMR_EL1 register before returning the value.
> > +
> > +	  If unsure, say Y.
> > +
> 
> An alternative for this would simply to prevent the enabling of pNMI
> on this platform.

There's also AC03_CPU_36, where the CPU goes into the weeds if you take
an asynchronous exception while fiddling with HCR_EL2. We don't have a
mitigation for it, and it can be pretty easily reproduced by using pNMIs
while running VMs.

So I agree, disabling pNMIs might be the easier way out.

[*] https://amperecomputing.com/assets/AmpereOne_Developer_ER_v0_80_20240823_28945022f4.pdf

-- 
Thanks,
Oliver