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(+)

-- 
2.47.0.338.g60cca15819-goog

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