From: Jeremy Linton <jeremy.linton@arm.com>
To: linux-arm-kernel@lists.infradead.org
Cc: catalin.marinas@arm.com, will.deacon@arm.com,
marc.zyngier@arm.com, suzuki.poulose@arm.com,
Dave.Martin@arm.com, shankerd@codeaurora.org,
julien.thierry@arm.com, mlangsdo@redhat.com,
stefan.wahren@i2se.com, Andre.Przywara@arm.com,
linux-kernel@vger.kernel.org,
Jeremy Linton <jeremy.linton@arm.com>
Subject: [v8 00/10] arm64: add system vulnerability sysfs entries
Date: Mon, 15 Apr 2019 16:21:19 -0500 [thread overview]
Message-ID: <20190415212129.1112-1-jeremy.linton@arm.com> (raw)
Arm64 machines should be displaying a human readable
vulnerability status to speculative execution attacks in
/sys/devices/system/cpu/vulnerabilities
This series enables that behavior by providing the expected
functions. Those functions expose the cpu errata and feature
states, as well as whether firmware is responding appropriately
to display the overall machine status. This means that in a
heterogeneous machine we will only claim the machine is mitigated
or safe if we are confident all booted cores are safe or
mitigated.
v7->v8: Fix latent build break when KVM_INDIRECT_VECTORS is not set.
Revert v7 ssbd tristate back to default safe bool. Since
__ssb_safe should be reliable now, make overall print
more dependent on it.
Tweak ssbd message to indicate prctl support.
v6->v7: Invert ssb white/black list logic so that we only mark
cores in the whitelist not affected when the firmware
fails to respond. Removed reviewed/tested tags for
just patch 9 because of this.
v5->v6:
Invert meltdown logic to display that a core is safe rather
than mitigated if the mitigation has been enabled on
machines that are safe. This can happen when the
mitigation was forced on via command line or KASLR.
This means that in order to detect if kpti is enabled
other methods must be used (look at dmesg) when the
machine isn't itself susceptible to meltdown.
Trivial whitespace tweaks.
Jeremy Linton (6):
arm64: Provide a command line to disable spectre_v2 mitigation
arm64: add sysfs vulnerability show for meltdown
arm64: Always enable spectrev2 vulnerability detection
arm64: add sysfs vulnerability show for spectre v2
arm64: Always enable ssb vulnerability detection
arm64: add sysfs vulnerability show for speculative store bypass
Marc Zyngier (2):
arm64: Advertise mitigation of Spectre-v2, or lack thereof
arm64: Use firmware to detect CPUs that are not affected by Spectre-v2
Mian Yousaf Kaukab (2):
arm64: add sysfs vulnerability show for spectre v1
arm64: enable generic CPU vulnerabilites support
.../admin-guide/kernel-parameters.txt | 8 +-
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/cpufeature.h | 4 -
arch/arm64/kernel/cpu_errata.c | 249 +++++++++++++-----
arch/arm64/kernel/cpufeature.c | 58 +++-
5 files changed, 232 insertions(+), 88 deletions(-)
--
2.20.1
next reply other threads:[~2019-04-15 21:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-15 21:21 Jeremy Linton [this message]
2019-04-15 21:21 ` [v8 01/10] arm64: Provide a command line to disable spectre_v2 mitigation Jeremy Linton
2019-04-15 21:21 ` [v8 02/10] arm64: add sysfs vulnerability show for spectre v1 Jeremy Linton
2019-04-15 21:21 ` [v8 03/10] arm64: add sysfs vulnerability show for meltdown Jeremy Linton
2019-04-15 21:21 ` [v8 04/10] arm64: Advertise mitigation of Spectre-v2, or lack thereof Jeremy Linton
2019-04-15 21:21 ` [v8 05/10] arm64: Use firmware to detect CPUs that are not affected by Spectre-v2 Jeremy Linton
2019-04-15 21:21 ` [v8 06/10] arm64: Always enable spectrev2 vulnerability detection Jeremy Linton
2019-04-15 21:21 ` [v8 07/10] arm64: add sysfs vulnerability show for spectre v2 Jeremy Linton
2019-04-15 21:21 ` [v8 08/10] arm64: Always enable ssb vulnerability detection Jeremy Linton
2019-04-15 21:21 ` [v8 09/10] arm64: add sysfs vulnerability show for speculative store bypass Jeremy Linton
2019-04-25 17:11 ` Stefan Wahren
2019-04-15 21:21 ` [v8 10/10] arm64: enable generic CPU vulnerabilites support Jeremy Linton
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=20190415212129.1112-1-jeremy.linton@arm.com \
--to=jeremy.linton@arm.com \
--cc=Andre.Przywara@arm.com \
--cc=Dave.Martin@arm.com \
--cc=catalin.marinas@arm.com \
--cc=julien.thierry@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=mlangsdo@redhat.com \
--cc=shankerd@codeaurora.org \
--cc=stefan.wahren@i2se.com \
--cc=suzuki.poulose@arm.com \
--cc=will.deacon@arm.com \
/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
all inboxes | Powered by JetHome®