Message-ID: <20241211213410.GB17486@willie-the-truck>
Date: Wed, 11 Dec 2024 21:34:11 +0000
From: Will Deacon <will@...nel.org>
To: Doug Anderson <dianders@...omium.org>
Cc: Catalin Marinas <catalin.marinas@....com>,
	Mark Rutland <mark.rutland@....com>,
	Julius Werner <jwerner@...omium.org>,
	Jeffrey Hugo <quic_jhugo@...cinc.com>,
	Roxana Bradescu <roxabee@...gle.com>,
	bjorn.andersson@....qualcomm.com,
	linux-arm-kernel@...ts.infradead.org,
	Trilok Soni <quic_tsoni@...cinc.com>, linux-arm-msm@...r.kernel.org,
	Anshuman Khandual <anshuman.khandual@....com>,
	Besar Wicaksono <bwicaksono@...dia.com>,
	D Scott Phillips <scott@...amperecomputing.com>,
	Easwar Hariharan <eahariha@...ux.microsoft.com>,
	Oliver Upton <oliver.upton@...ux.dev>, linux-kernel@...r.kernel.org,
	james.morse@....com
Subject: Re: [PATCH 0/6] arm64: errata: Add Qualcomm CPUs to the Spectre
 mitigation lists

On Tue, Dec 10, 2024 at 08:53:46AM -0800, Doug Anderson wrote:
> On Tue, Dec 10, 2024 at 7:56 AM Will Deacon <will@...nel.org> wrote:
> > On Mon, Dec 09, 2024 at 09:43:10AM -0800, Douglas Anderson wrote:
> > >
> > > Since Qualcomm CPUs are all derivatives of ARM cores they all have
> > > unique MIDR values. This means that the tables listing necessary
> > > Spectre mitigations need special entries for them. However, those
> > > entries are not present and that means that some Spectre mitigations
> > > are lacking for Qualcomm CPUs.
> > >
> > > I've made an attempt at **GUESSING** what the right patches should be
> > > to enable mitigations for Qualcomm CPUs. This is mostly me searching
> > > the web to figure out what ARM cores various Qualcomm cores are based
> > > off of.
> > >
> > > These patches get more and more sketchy as the series progresses and I
> > > have noted that the later patces DON'T EVEN COMPILE. I have included
> > > them to make it obvious that I think these cores are affected even if
> > > I don't have all the right information to mitigate them. Hopefully
> > > Qualcomm can come and fix this mess for me.
> > >
> > > I'll note that I am certainly no expert on Spectre. Mostly I ended up
> > > here running `lscpu` on a device and noticing that it thought that it
> > > wasn't affected by Spectre v2 when I thought it was.
> >
> > Whilst only Qualcomm can say definitively whether or not they are
> > affected (and what values of 'k' are required for the loop-based
> > workarounds), I can't help but wonder whether the current mitigation
> > code is structured the wrong way around in this case.
> >
> > It looks to me like we don't have a way to identify a "vulnerable" CPU
> > for Spectre-BHB; either a CPU has some sort of mitigation or it's
> > unaffected. That means that there's very little incentive for vendors
> > to add their CPUs to one of the lists -- if they do nothing, userspace
> > is told that everything is golden and they don't pay the performance
> > hit of a workaround!
> >
> > So I think we should consider turning this on its head and assume that
> > CPUs we don't know about are vulnerable, having a list of unaffected
> > cores that predate the introduction of CSV2.3 which can be queried by
> > is_spectre_bhb_affected(). We can do that without the assistance of the
> > CPU vendors.
> >
> > Does that make sense, or did I miss something?
> 
> It makes sense to me. I'm not sure I'd be the best person to actually
> implement that, though. Maybe someone CCed on this thread could take a
> stab at it? It seems like folks from ARM would know the most about the
> various mitigations and which pre-CSV2.3 cores were safe.

I think we could start with an empty list tbh. If you take a stab at it,
I'm happy to review it. Folks with knowledge about the specific CPUs
can send patches on top.

Will

Powered by blists - more mailing lists