Hi, On Tue, Dec 10, 2024 at 7:56 AM Will Deacon <will@xxxxxxxxxx> wrote: > > Hi Doug, > > 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. -Doug