From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: x86@kernel.org
Cc: linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Tyler Hicks <tyhicks@canonical.com>,
Waiman Long <longman@redhat.com>,
Peter Zijlstra <peterz@infradead.org>
Subject: [PATCH RFC] x86/speculation: Clarify Spectre-v2 mitigation when STIBP/IBPB features are unsupported
Date: Tue, 21 Jan 2020 17:02:57 +0100 [thread overview]
Message-ID: <20200121160257.302999-1-vkuznets@redhat.com> (raw)
When STIBP/IBPB features are not supported (no microcode update,
AWS/Azure/... instances deliberately hiding SPEC_CTRL for performance
reasons,...) /sys/devices/system/cpu/vulnerabilities/spectre_v2 looks like
Mitigation: Full generic retpoline, STIBP: disabled, RSB filling
and this looks imperfect. In particular, STIBP is 'disabled' and 'IBPB'
is not mentioned while both features are just not supported. Also, for
STIBP the 'disabled' state (SPECTRE_V2_USER_NONE) can represent both
the absence of hardware support and deliberate user's choice
(spectre_v2_user=off)
Make the following adjustments:
- Output 'unsupported' for both STIBP/IBPB when there's no support in
hardware.
- Output 'unneeded' for STIBP when SMT is disabled/missing (and this
switch_to_cond_stibp is off).
RFC. Some tools out there may be looking at this information so by
changing the output we're breaking them. Also, it may make sense to
separate kernel and userspace protections and switch to something like
Mitigation: Kernel: Full generic retpoline, RSB filling; Userspace:
Vulnerable
for the above mentioned case.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
Documentation/admin-guide/hw-vuln/spectre.rst | 3 +++
arch/x86/kernel/cpu/bugs.c | 9 +++++++--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/hw-vuln/spectre.rst b/Documentation/admin-guide/hw-vuln/spectre.rst
index e05e581af5cf..2b8a42d0c57b 100644
--- a/Documentation/admin-guide/hw-vuln/spectre.rst
+++ b/Documentation/admin-guide/hw-vuln/spectre.rst
@@ -385,6 +385,7 @@ The possible values in this file are:
an x86 only feature. For more details see below.
=================== ========================================================
+ 'IBPB: unsupported' IBPB is not supported by hardware
'IBPB: disabled' IBPB unused
'IBPB: always-on' Use IBPB on all tasks
'IBPB: conditional' Use IBPB on SECCOMP or indirect branch restricted tasks
@@ -396,6 +397,8 @@ The possible values in this file are:
only feature. For more details see below.
==================== ========================================================
+ 'STIBP: unsupported' STIBP is not supported by hardware
+ 'STIBP: unneeded' STIBP is not needed because SMT is disabled
'STIBP: disabled' STIBP unused
'STIBP: forced' Use STIBP on all tasks
'STIBP: conditional' Use STIBP on SECCOMP or indirect branch restricted tasks
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 8bf64899f56a..d72a36fe042b 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -1496,7 +1496,10 @@ static char *stibp_state(void)
switch (spectre_v2_user) {
case SPECTRE_V2_USER_NONE:
- return ", STIBP: disabled";
+ if (boot_cpu_has(X86_FEATURE_STIBP))
+ return ", STIBP: disabled";
+ else
+ return ", STIBP: unsupported";
case SPECTRE_V2_USER_STRICT:
return ", STIBP: forced";
case SPECTRE_V2_USER_STRICT_PREFERRED:
@@ -1505,6 +1508,8 @@ static char *stibp_state(void)
case SPECTRE_V2_USER_SECCOMP:
if (static_key_enabled(&switch_to_cond_stibp))
return ", STIBP: conditional";
+ else
+ return ", STIBP: unneeded";
}
return "";
}
@@ -1518,7 +1523,7 @@ static char *ibpb_state(void)
return ", IBPB: conditional";
return ", IBPB: disabled";
}
- return "";
+ return ", IBPB: unsupported";
}
static ssize_t cpu_show_common(struct device *dev, struct device_attribute *attr,
--
2.24.1
next reply other threads:[~2020-01-21 16:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-21 16:02 Vitaly Kuznetsov [this message]
2020-01-21 16:14 ` Borislav Petkov
2020-01-21 16:24 ` Vitaly Kuznetsov
2020-01-21 16:22 ` Waiman Long
2020-01-21 16:37 ` Vitaly Kuznetsov
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=20200121160257.302999-1-vkuznets@redhat.com \
--to=vkuznets@redhat.com \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tyhicks@canonical.com \
--cc=x86@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
all inboxes | Powered by JetHome®