From: mark gross <mgross@linux.intel.com>
To: speck@linutronix.de
Subject: [MODERATED] [PATCH 0/4] v5 more sampling fun 0
Date: Thu, 9 Apr 2020 11:10:52 -0700 [thread overview]
Message-ID: <E1jMblG-000S8O-OD@mtg-dev> (raw)
From: mark gross <mgross@linux.intel.com>
Subject: [PATCH 0/4] v6 more sampling fun
This version of the Special Register Buffer Data Sampling has been updated to
address feedback gotten. Including:
* is based on linus/master from this AM.
* cleanups and changes driven by review feedback from Josh and Thomas.
* addresses the case of intel fusing TSX off on lower end SKU's
* spits out some refactoring from the main patch to better isolate the SRBDS
specific changes.
Thanks to all who have given me feedback on this.
---
Special Register Buffer Data Sampling is a sampling type of vulnerability that
leaks data across cores sharing the HW-RNG for vulnerable processors.
This leak is fixed by a microcode update and is enabled by default.
This new microcode serializes processor access during execution of RDRAND or
RDSEED. It ensures that the shared buffer is overwritten before it is released
for reuse.
The mitigation impacts the throughput of the RDRAND and RDSEED instructions and
latency of RT processing running on the socket while executing RDRAND or
RDSEED. The micro benchmarks calling RDRAND many times show a slowdown.
This patch set enables kernel command line control of this mitigation and
exports vulnerability and mitigation status.
This patch set includes 3 patches:
* The first patch adds steppings to x86_cpu_id structure and related macros
* The second patch enables the command line control of the mitigation as well
as the sysfs export of vulnerability status.
* The third patch has the Documentation/admin-guide/hw-vuln documentation for
this issue and the control over the mitigation.
mark gross (4):
x86/cpu: Add stepping field to x86_cpu_id structure
x86/cpu: clean up cpu_matches
x86/speculation: Special Register Buffer Data Sampling (SRBDS)
mitigation control.
x86/speculation: SRBDS vulnerability and mitigation documentation
.../ABI/testing/sysfs-devices-system-cpu | 1 +
Documentation/admin-guide/hw-vuln/index.rst | 1 +
.../special-register-buffer-data-sampling.rst | 148 ++++++++++++++++++
.../admin-guide/kernel-parameters.txt | 20 +++
arch/x86/include/asm/cpu_device_id.h | 26 ++-
arch/x86/include/asm/cpufeatures.h | 2 +
arch/x86/include/asm/msr-index.h | 4 +
arch/x86/kernel/cpu/bugs.c | 116 ++++++++++++++
arch/x86/kernel/cpu/common.c | 68 ++++++--
arch/x86/kernel/cpu/cpu.h | 2 +
arch/x86/kernel/cpu/match.c | 7 +-
drivers/base/cpu.c | 8 +
include/linux/mod_devicetable.h | 2 +
13 files changed, 390 insertions(+), 15 deletions(-)
create mode 100644 Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst
--
2.17.1
reply other threads:[~2020-04-09 18:18 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=E1jMblG-000S8O-OD@mtg-dev \
--to=mgross@linux.intel.com \
--cc=speck@linutronix.de \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).