linux-kernel - Re: [PATCH 0/5] arm64: Add workaround for Cortex-A77 erratum 1542418

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]

Date:   Wed, 20 Nov 2019 19:18:55 +0000
From:   Will Deacon <will@...nel.org>
To:     Suzuki K Poulose <suzuki.poulose@....com>
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        james.morse@....com, catalin.marinas@....com, mark.rutland@....com,
        maz@...nel.org
Subject: Re: [PATCH 0/5] arm64: Add workaround for Cortex-A77 erratum 1542418

On Fri, Nov 15, 2019 at 01:14:07AM +0000, Suzuki K Poulose wrote:
> On 11/14/2019 04:39 PM, Will Deacon wrote:
> > On Thu, Nov 14, 2019 at 02:59:13PM +0000, Suzuki K Poulose wrote:
> > > This series adds workaround for Arm erratum 1542418 which affects
> > > Cortex-A77 cores (r0p0 - r1p0). Affected cores may execute stale
> > > instructions from the L0 macro-op cache violating the
> > > prefetch-speculation-protection guaranteed by the architecture.
> > > This happens when the when the branch predictor bases its predictions
> > > on a branch at this address on the stale history due to ASID or VMID
> > > reuse.
> > 
> > Two immediate questions:
> > 
> >   1. Can we disable the L0 MOP cache?
> Yes, but it hurts performance.
> 
> >   2. Can we invalidate the branch predictor? If Spectre-v2 taught us
> >      anything it's that removing those instructions was a mistake!
> 
> The workaround suggested is actually invalidating the branch history
> but in a costly way. I am unaware of any.
> > Moving on...
> > 
> > Have you reproduced this at top-level? If I recall the
> > prefetch-speculation-protection, it's designed to protect against the
> > case where you have a direct branch:
> 
> No, see below.
> 
> > 
> > addr:	B	foo
> > 
> > and another CPU writes out a new function:
> > 
> > bar:
> > 	insn0
> > 	...
> > 	insnN
> > 
> > before doing any necessary maintenance and then patches the original
> > branch to:
> > 
> > addr:	B	bar
> > 
> > The idea is that a concurrently executing CPU could mispredict the original
> > branch to point at 'bar', fetch the instructions before they've been written
> > out and then confirm the prediction by looking at the newly written branch
> > instruction. Even without the prefetch-speculation-protection, that's
> > fairly difficult to achieve in practice: you'd need to be doing something
> > like reusing memory to hold the instructions so that the initial
> > misprediction occurs.
> > 
> > How does A77 stop this from occurring when the ASID is not reallocated (e.g.
> > the example above)? Is the MOP cache flushed somehow?
> 
> IIUC, The MOP cache is flushed on I-cache invalidate, thus it is fine.	

Hmm, so this is interesting. Does that mean we could do a local I-cache
invalidation in check_and_switch_context() at the same as doing the local
TLBI after a rollover?

I still don't grok the failure case, though, because assuming A77 has IDC=0,
then won't you see the I-cache maintenance from userspace anyway?

Will