[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241210155604.GA15918@willie-the-truck>
Date: Tue, 10 Dec 2024 15:56:04 +0000
From: Will Deacon <will@...nel.org>
To: Douglas Anderson <dianders@...omium.org>
Cc: Catalin Marinas <catalin.marinas@....com>,
Mark Rutland <mark.rutland@....com>,
Julius Werner <jwerner@...omium.org>,
Jeffrey Hugo <quic_jhugo@...cinc.com>,
Roxana Bradescu <roxabee@...gle.com>,
bjorn.andersson@....qualcomm.com,
linux-arm-kernel@...ts.infradead.org,
Trilok Soni <quic_tsoni@...cinc.com>, linux-arm-msm@...r.kernel.org,
Anshuman Khandual <anshuman.khandual@....com>,
Besar Wicaksono <bwicaksono@...dia.com>,
D Scott Phillips <scott@...amperecomputing.com>,
Easwar Hariharan <eahariha@...ux.microsoft.com>,
Oliver Upton <oliver.upton@...ux.dev>, linux-kernel@...r.kernel.org,
james.morse@....com
Subject: Re: [PATCH 0/6] arm64: errata: Add Qualcomm CPUs to the Spectre
mitigation lists
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
Powered by blists - more mailing lists