Hi, On Thu, Dec 19, 2024 at 9:51 AM Will Deacon <will@xxxxxxxxxx> wrote: > > On Fri, Dec 13, 2024 at 04:52:02PM -0800, Douglas Anderson wrote: > > The code for detecting CPUs that are vulnerable to Spectre BHB was > > based on a hardcoded list of CPU IDs that were known to be affected. > > Unfortunately, the list mostly only contained the IDs of standard ARM > > cores. The IDs for many cores that are minor variants of the standard > > ARM cores (like many Qualcomm Kyro CPUs) weren't listed. This led the > > code to assume that those variants were not affected. > > > > Flip the code on its head and instead list CPU IDs for cores that are > > known to be _not_ affected. Now CPUs will be assumed vulnerable until > > added to the list saying that they're safe. > > > > As of right now, the only CPU IDs added to the "unaffected" list are > > ARM Cortex A35, A53, and A55. This list was created by looking at > > older cores listed in cputype.h that weren't listed in the "affected" > > list previously. > > There's a list of affected CPUs from Arm here: > > https://developer.arm.com/Arm%20Security%20Center/Spectre-BHB > > (obviously only covers their own designs). > > So it looks like A510 and A520 should be unaffected too, although I > didn't check exhaustively. It also looks like A715 is affected but the > whitepaper doesn't tell you what version of 'k' to use... > > > Unfortunately, while this solution is better than what we had before, > > it's still an imperfect solution. Specifically there are two ways to > > mitigate Spectre BHB and one of those ways is parameterized with a "k" > > value indicating how many loops are needed to mitigate. If we have an > > unknown CPU ID then we've got to guess about how to mitigate it. Since > > more cores seem to be mitigated by looping (and because it's unlikely > > that the needed FW code will be in place for FW mitigation for unknown > > cores), we'll choose looping for unknown CPUs and choose the highest > > "k" value of 32. > > I don't think we should guess. Just say vulnerable. Ah, I see. So the series won't actually _fix_ anyone, it will just properly report that we're vulnerable. I guess that works. > > The downside of our guessing is that some CPUs may now report as > > "mitigated" when in reality they should need a firmware mitigation. > > We'll choose to put a WARN_ON splat in the logs in this case any time > > we had to make a guess since guessing the right mitigation is pretty > > awful. Hopefully this will encourage CPU vendors to add their CPU IDs > > to the list. > > Hmm. We shouldn't have to guess here as the firmware mitigation is > discoverable. So if it's unavailable and we're running an a CPU which > needs it, then we're vulnerable. Sure. -Doug
