Thread (24 messages) 24 messages, 5 authors, 2024-12-16

Re: [PATCH 0/6] arm64: errata: Add Qualcomm CPUs to the Spectre mitigation lists

From: Will Deacon <will@kernel.org>
Date: 2024-12-11 21:34:17
Also in: linux-arm-msm, lkml

On Tue, Dec 10, 2024 at 08:53:46AM -0800, Doug Anderson wrote:
On Tue, Dec 10, 2024 at 7:56 AM Will Deacon [off-list ref] wrote:
quoted
On Mon, Dec 09, 2024 at 09:43:10AM -0800, Douglas Anderson wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help