From: Douglas Anderson <dianders@chromium.org>
To: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>
Cc: Roxana Bradescu <roxabee@google.com>,
Julius Werner <jwerner@chromium.org>,
bjorn.andersson@oss.qualcomm.com,
linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org,
Jeffrey Hugo <quic_jhugo@quicinc.com>,
Trilok Soni <quic_tsoni@quicinc.com>,
Douglas Anderson <dianders@chromium.org>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Besar Wicaksono <bwicaksono@nvidia.com>,
D Scott Phillips <scott@os.amperecomputing.com>,
Easwar Hariharan <eahariha@linux.microsoft.com>,
James Morse <james.morse@arm.com>,
Kent Overstreet <kent.overstreet@linux.dev>,
Oliver Upton <oliver.upton@linux.dev>,
Suren Baghdasaryan <surenb@google.com>,
linux-kernel@vger.kernel.org
Subject: [PATCH v3 0/3] arm64: errata: Rework Spectre BHB mitigations to not assume "safe"
Date: Thu, 19 Dec 2024 12:53:20 -0800 [thread overview]
Message-ID: <20241219205426.2275508-1-dianders@chromium.org> (raw)
Recently I realized that a device with some Qualcomm Kryo 4xx cores
reported in `lscpu` that it was _not_ vulnerable to Spectre BHB. This
seemed unlikely to me.
I wrote up a patch series to attempt (with a lot of guesswork) to add
Qualcomm cores to the tables governing how the Spectre BHB mitigation
worked.
In response to that patch, Will suggested that I flip the mitigation
on its head and assume things are vulnerable until we find that
they're not [1]. This patch series _attempts_ to accomplish that.
In case it's not obvious, v2 of this patch series was pretty different
than v1 because it flips the logic on its head. Some of the patches
carried over, though.
v3 is yet more different, avoiding the guesses (and thus dropping
some patches) and also incorporating feedback from Julius in response
to v2.
As a last caveat, 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.
Link to prev versions:
v1: https://lore.kernel.org/r/20241209174430.2904353-1-dianders@chromium.org/
v2: https://lore.kernel.org/r/20241214005248.198803-1-dianders@chromium.org
[1] https://lore.kernel.org/r/20241211213410.GB17486@willie-the-truck
Changes in v3:
- Don't guess the mitigation; just report unknown cores as vulnerable.
- Restructure the code since is_spectre_bhb_affected() defaults to true
- arm64: cputype: Add MIDR_CORTEX_A76AE
- arm64: errata: Add newer ARM cores to the spectre_bhb_loop_affected() lists
Changes in v2:
- arm64: errata: Assume that unknown CPUs _are_ vulnerable to Spectre BHB
Douglas Anderson (3):
arm64: errata: Assume that unknown CPUs _are_ vulnerable to Spectre
BHB
arm64: cputype: Add MIDR_CORTEX_A76AE
arm64: errata: Add newer ARM cores to the spectre_bhb_loop_affected()
lists
arch/arm64/include/asm/cputype.h | 2 +
arch/arm64/include/asm/spectre.h | 1 -
arch/arm64/kernel/proton-pack.c | 157 ++++++++++++++++++-------------
3 files changed, 92 insertions(+), 68 deletions(-)
--
2.47.1.613.gc27f4b7a9f-goog
next reply other threads:[~2024-12-19 20:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-19 20:53 Douglas Anderson [this message]
2024-12-19 20:53 ` [PATCH v3 1/3] arm64: errata: Assume that unknown CPUs _are_ vulnerable to Spectre BHB Douglas Anderson
2024-12-20 16:33 ` Julius Werner
2025-01-06 22:32 ` Doug Anderson
2025-01-06 22:48 ` Florian Fainelli
2024-12-19 20:53 ` [PATCH v3 2/3] arm64: cputype: Add MIDR_CORTEX_A76AE Douglas Anderson
2024-12-19 20:53 ` [PATCH v3 3/3] arm64: errata: Add newer ARM cores to the spectre_bhb_loop_affected() lists Douglas Anderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241219205426.2275508-1-dianders@chromium.org \
--to=dianders@chromium.org \
--cc=anshuman.khandual@arm.com \
--cc=bjorn.andersson@oss.qualcomm.com \
--cc=bwicaksono@nvidia.com \
--cc=catalin.marinas@arm.com \
--cc=eahariha@linux.microsoft.com \
--cc=james.morse@arm.com \
--cc=jwerner@chromium.org \
--cc=kent.overstreet@linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=oliver.upton@linux.dev \
--cc=quic_jhugo@quicinc.com \
--cc=quic_tsoni@quicinc.com \
--cc=roxabee@google.com \
--cc=scott@os.amperecomputing.com \
--cc=surenb@google.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox