| Message ID | 20241209174430.2904353-1-dianders@chromium.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | arm64: errata: Add Qualcomm CPUs to the Spectre mitigation lists | expand |
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? Will
Hi, On Tue, Dec 10, 2024 at 7:56 AM Will Deacon <will@kernel.org> 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
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@kernel.org> 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
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. Douglas Anderson (6): arm64: errata: Add QCOM_KRYO_4XX_GOLD to the spectre_bhb_k24_list arm64: errata: Add QCOM_KRYO_2XX_GOLD to the spectre_bhb_firmware_mitigated_list arm64: cputype: Add QCOM_CPU_PART_KRYO_3XX_GOLD arm64: errata: Add QCOM_KRYO_3XX_GOLD to the spectre_bhb_firmware_mitigated_list arm64: errata: Add QCOM_KRYO_5XX_GOLD to the spectre_bhb_k24_list arm64: errata: Add QCOM_KRYO_6XX_GOLD/PRIME to the spectre_bhb_k32_list arch/arm64/include/asm/cputype.h | 2 ++ arch/arm64/kernel/proton-pack.c | 6 ++++++ 2 files changed, 8 insertions(+)