linux-kernel - [PATCH v3 0/3] arm64: errata: Rework Spectre BHB mitigations to not assume "safe"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241219205426.2275508-1-dianders@chromium.org>
Date: Thu, 19 Dec 2024 12:53:20 -0800
From: Douglas Anderson <dianders@...omium.org>
To: Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>,
	Mark Rutland <mark.rutland@....com>
Cc: Roxana Bradescu <roxabee@...gle.com>,
	Julius Werner <jwerner@...omium.org>,
	bjorn.andersson@....qualcomm.com,
	linux-arm-kernel@...ts.infradead.org,
	linux-arm-msm@...r.kernel.org,
	Jeffrey Hugo <quic_jhugo@...cinc.com>,
	Trilok Soni <quic_tsoni@...cinc.com>,
	Douglas Anderson <dianders@...omium.org>,
	Anshuman Khandual <anshuman.khandual@....com>,
	Besar Wicaksono <bwicaksono@...dia.com>,
	D Scott Phillips <scott@...amperecomputing.com>,
	Easwar Hariharan <eahariha@...ux.microsoft.com>,
	James Morse <james.morse@....com>,
	Kent Overstreet <kent.overstreet@...ux.dev>,
	Oliver Upton <oliver.upton@...ux.dev>,
	Suren Baghdasaryan <surenb@...gle.com>,
	linux-kernel@...r.kernel.org
Subject: [PATCH v3 0/3] arm64: errata: Rework Spectre BHB mitigations to not assume "safe"

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