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@xxxxxxxxxx> 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
