Some Qualcomm processors/SoCs on the mainline Linux kernel are left vulnerable to Spectre security issues since Qualcomm hasn't upstreamed patches for properly treating affected CPU cores to their relevant mitigations. But a new patch series from a Google engineer is working to get those Qualcomm CPU security mitigations in order.

Google engineer Douglas Anderson sent out a set of patches this past week for aiming to get the Qualcomm CPU cores needing Spectre security mitigations in place for the mainline Linux kernel. Douglas Anderson explained in the patch series cover letter:

"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 patches 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."

[1]This patch series is that initial attempt at treating Qualcomm CPU cores, mostly around Spectre-BHB.

In helping to get more ARM CPU custom core vendors to properly maintain or recognize what CPUs are vulnerable (or not) to a given issue like Spectre-BHB, longtime ARM Linux engineer Will Deacon raised the idea of inverting some of the handling to make more assumptions of being affected by something unless opting out. That way the CPU vendor is more inclined to recognize one of their products/cores as not being affected and thus patching to opt-out to avoid any possible performance penalties. As it stands now some CPU vendors may not be too inclined for opting into security mitigations due to often associated performance penalties, acknowledging the hardware vulnerabilities, or simply oversight/resource constraints. Will Deacon [2]explained :

"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."

We'll see what comes of this effort and/or if Qualcomm steps up to better acknowledge needed mitigations by their mainline kernel for their wares.



[1] https://lore.kernel.org/lkml/20241209174430.2904353-1-dianders@chromium.org/

[2] https://lore.kernel.org/lkml/20241210155604.GA15918@willie-the-truck/