License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 14:07:57 +00:00
// SPDX-License-Identifier: GPL-2.0
2007-05-02 17:27:12 +00:00
/*
* Copyright ( C ) 1994 Linus Torvalds
*
* Cyrix stuff , June 1998 by :
* - Rafael R . Reilova ( moved everything from head . S ) ,
* < rreilova @ ececs . uc . edu >
* - Channing Corn ( tests & fixes ) ,
* - Andrew D . Balsa ( code cleanup ) .
*/
# include <linux/init.h>
# include <linux/utsname.h>
2018-01-07 21:48:01 +00:00
# include <linux/cpu.h>
2018-01-25 23:50:28 +00:00
# include <linux/module.h>
2018-04-29 13:26:40 +00:00
# include <linux/nospec.h>
# include <linux/prctl.h>
2018-11-25 18:33:39 +00:00
# include <linux/sched/smt.h>
2020-06-09 04:32:42 +00:00
# include <linux/pgtable.h>
2022-02-18 19:49:08 +00:00
# include <linux/bpf.h>
2018-01-11 21:46:26 +00:00
2018-04-29 13:01:37 +00:00
# include <asm/spec-ctrl.h>
2018-01-11 21:46:26 +00:00
# include <asm/cmdline.h>
2007-07-31 07:39:20 +00:00
# include <asm/bugs.h>
2007-05-02 17:27:12 +00:00
# include <asm/processor.h>
2008-01-30 12:30:39 +00:00
# include <asm/processor-flags.h>
2021-10-15 01:16:39 +00:00
# include <asm/fpu/api.h>
2007-05-02 17:27:12 +00:00
# include <asm/msr.h>
2018-07-13 14:23:16 +00:00
# include <asm/vmx.h>
2007-05-02 17:27:12 +00:00
# include <asm/paravirt.h>
# include <asm/alternative.h>
2017-05-08 22:58:11 +00:00
# include <asm/set_memory.h>
2018-01-12 17:49:25 +00:00
# include <asm/intel-family.h>
2018-06-13 22:48:26 +00:00
# include <asm/e820/api.h>
2018-06-18 07:59:54 +00:00
# include <asm/hypervisor.h>
2020-07-16 19:23:59 +00:00
# include <asm/tlbflush.h>
2022-11-28 17:24:51 +00:00
# include <asm/cpu.h>
2007-05-02 17:27:12 +00:00
2018-12-04 23:34:56 +00:00
# include "cpu.h"
x86/speculation: Enable Spectre v1 swapgs mitigations
The previous commit added macro calls in the entry code which mitigate the
Spectre v1 swapgs issue if the X86_FEATURE_FENCE_SWAPGS_* features are
enabled. Enable those features where applicable.
The mitigations may be disabled with "nospectre_v1" or "mitigations=off".
There are different features which can affect the risk of attack:
- When FSGSBASE is enabled, unprivileged users are able to place any
value in GS, using the wrgsbase instruction. This means they can
write a GS value which points to any value in kernel space, which can
be useful with the following gadget in an interrupt/exception/NMI
handler:
if (coming from user space)
swapgs
mov %gs:<percpu_offset>, %reg1
// dependent load or store based on the value of %reg
// for example: mov %(reg1), %reg2
If an interrupt is coming from user space, and the entry code
speculatively skips the swapgs (due to user branch mistraining), it
may speculatively execute the GS-based load and a subsequent dependent
load or store, exposing the kernel data to an L1 side channel leak.
Note that, on Intel, a similar attack exists in the above gadget when
coming from kernel space, if the swapgs gets speculatively executed to
switch back to the user GS. On AMD, this variant isn't possible
because swapgs is serializing with respect to future GS-based
accesses.
NOTE: The FSGSBASE patch set hasn't been merged yet, so the above case
doesn't exist quite yet.
- When FSGSBASE is disabled, the issue is mitigated somewhat because
unprivileged users must use prctl(ARCH_SET_GS) to set GS, which
restricts GS values to user space addresses only. That means the
gadget would need an additional step, since the target kernel address
needs to be read from user space first. Something like:
if (coming from user space)
swapgs
mov %gs:<percpu_offset>, %reg1
mov (%reg1), %reg2
// dependent load or store based on the value of %reg2
// for example: mov %(reg2), %reg3
It's difficult to audit for this gadget in all the handlers, so while
there are no known instances of it, it's entirely possible that it
exists somewhere (or could be introduced in the future). Without
tooling to analyze all such code paths, consider it vulnerable.
Effects of SMAP on the !FSGSBASE case:
- If SMAP is enabled, and the CPU reports RDCL_NO (i.e., not
susceptible to Meltdown), the kernel is prevented from speculatively
reading user space memory, even L1 cached values. This effectively
disables the !FSGSBASE attack vector.
- If SMAP is enabled, but the CPU *is* susceptible to Meltdown, SMAP
still prevents the kernel from speculatively reading user space
memory. But it does *not* prevent the kernel from reading the
user value from L1, if it has already been cached. This is probably
only a small hurdle for an attacker to overcome.
Thanks to Dave Hansen for contributing the speculative_smap() function.
Thanks to Andrew Cooper for providing the inside scoop on whether swapgs
is serializing on AMD.
[ tglx: Fixed the USER fence decision and polished the comment as suggested
by Dave Hansen ]
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Dave Hansen <dave.hansen@intel.com>
2019-07-08 16:52:26 +00:00
static void __init spectre_v1_select_mitigation ( void ) ;
2018-01-11 21:46:26 +00:00
static void __init spectre_v2_select_mitigation ( void ) ;
2022-06-14 21:15:56 +00:00
static void __init retbleed_select_mitigation ( void ) ;
static void __init spectre_v2_user_select_mitigation ( void ) ;
2018-04-26 02:04:21 +00:00
static void __init ssb_select_mitigation ( void ) ;
2018-06-13 22:48:26 +00:00
static void __init l1tf_select_mitigation ( void ) ;
2019-02-18 21:04:08 +00:00
static void __init mds_select_mitigation ( void ) ;
2022-05-20 03:28:10 +00:00
static void __init md_clear_update_mitigation ( void ) ;
2022-05-20 03:30:12 +00:00
static void __init md_clear_select_mitigation ( void ) ;
2019-10-23 09:30:45 +00:00
static void __init taa_select_mitigation ( void ) ;
2022-05-20 03:29:11 +00:00
static void __init mmio_select_mitigation ( void ) ;
2020-04-16 15:54:04 +00:00
static void __init srbds_select_mitigation ( void ) ;
2021-04-26 19:42:30 +00:00
static void __init l1d_flush_select_mitigation ( void ) ;
2018-01-11 21:46:26 +00:00
2022-06-14 21:15:52 +00:00
/* The base value of the SPEC_CTRL MSR without task-specific bits set */
2018-09-25 12:38:55 +00:00
u64 x86_spec_ctrl_base ;
2018-05-12 18:49:16 +00:00
EXPORT_SYMBOL_GPL ( x86_spec_ctrl_base ) ;
2022-06-14 21:15:52 +00:00
/* The current value of the SPEC_CTRL MSR with task-specific bits set */
DEFINE_PER_CPU ( u64 , x86_spec_ctrl_current ) ;
EXPORT_SYMBOL_GPL ( x86_spec_ctrl_current ) ;
2018-09-25 12:38:55 +00:00
static DEFINE_MUTEX ( spec_ctrl_mutex ) ;
2018-04-26 02:04:18 +00:00
2022-11-30 15:25:51 +00:00
/* Update SPEC_CTRL MSR and its cached copy unconditionally */
static void update_spec_ctrl ( u64 val )
{
this_cpu_write ( x86_spec_ctrl_current , val ) ;
wrmsrl ( MSR_IA32_SPEC_CTRL , val ) ;
}
2022-06-14 21:15:52 +00:00
/*
* Keep track of the SPEC_CTRL MSR value for the current task , which may differ
* from x86_spec_ctrl_base due to STIBP / SSB in __speculation_ctrl_update ( ) .
*/
2022-11-30 15:25:51 +00:00
void update_spec_ctrl_cond ( u64 val )
2022-06-14 21:15:52 +00:00
{
if ( this_cpu_read ( x86_spec_ctrl_current ) = = val )
return ;
this_cpu_write ( x86_spec_ctrl_current , val ) ;
2022-06-14 21:15:54 +00:00
/*
* When KERNEL_IBRS this MSR is written on return - to - user , unless
* forced the update can be delayed until that time .
*/
2022-11-30 15:25:51 +00:00
if ( ! cpu_feature_enabled ( X86_FEATURE_KERNEL_IBRS ) )
2022-06-14 21:15:54 +00:00
wrmsrl ( MSR_IA32_SPEC_CTRL , val ) ;
2022-06-14 21:15:52 +00:00
}
2023-01-12 19:43:34 +00:00
noinstr u64 spec_ctrl_current ( void )
2022-06-14 21:15:58 +00:00
{
return this_cpu_read ( x86_spec_ctrl_current ) ;
}
EXPORT_SYMBOL_GPL ( spec_ctrl_current ) ;
2018-04-26 02:04:24 +00:00
/*
* AMD specific MSR info for Speculative Store Bypass control .
2018-05-09 19:41:38 +00:00
* x86_amd_ls_cfg_ssbd_mask is initialized in identify_boot_cpu ( ) .
2018-04-26 02:04:24 +00:00
*/
u64 __ro_after_init x86_amd_ls_cfg_base ;
2018-05-09 19:41:38 +00:00
u64 __ro_after_init x86_amd_ls_cfg_ssbd_mask ;
2018-04-26 02:04:24 +00:00
2018-12-05 19:49:27 +00:00
/* Control conditional STIBP in switch_to() */
2018-11-25 18:33:45 +00:00
DEFINE_STATIC_KEY_FALSE ( switch_to_cond_stibp ) ;
2018-11-25 18:33:49 +00:00
/* Control conditional IBPB in switch_mm() */
DEFINE_STATIC_KEY_FALSE ( switch_mm_cond_ibpb ) ;
/* Control unconditional IBPB in switch_mm() */
DEFINE_STATIC_KEY_FALSE ( switch_mm_always_ibpb ) ;
2018-11-25 18:33:45 +00:00
2019-02-18 22:42:51 +00:00
/* Control MDS CPU buffer clear before returning to user space */
DEFINE_STATIC_KEY_FALSE ( mds_user_clear ) ;
2019-02-27 11:48:14 +00:00
EXPORT_SYMBOL_GPL ( mds_user_clear ) ;
2019-02-18 22:04:01 +00:00
/* Control MDS CPU buffer clear before idling (halt, mwait) */
DEFINE_STATIC_KEY_FALSE ( mds_idle_clear ) ;
EXPORT_SYMBOL_GPL ( mds_idle_clear ) ;
2019-02-18 22:42:51 +00:00
2021-04-26 19:42:30 +00:00
/*
* Controls whether l1d flush based mitigations are enabled ,
* based on hw features and admin setting via boot parameter
* defaults to false
*/
DEFINE_STATIC_KEY_FALSE ( switch_mm_cond_l1d_flush ) ;
2022-05-20 03:29:11 +00:00
/* Controls CPU Fill buffer clear before KVM guest MMIO accesses */
DEFINE_STATIC_KEY_FALSE ( mmio_stale_data_clear ) ;
EXPORT_SYMBOL_GPL ( mmio_stale_data_clear ) ;
2007-05-02 17:27:12 +00:00
void __init check_bugs ( void )
{
identify_boot_cpu ( ) ;
2013-04-08 15:57:44 +00:00
2018-07-13 14:23:24 +00:00
/*
* identify_boot_cpu ( ) initialized SMT support information , let the
* core code know .
*/
cpu/hotplug: Fix "SMT disabled by BIOS" detection for KVM
With the following commit:
73d5e2b47264 ("cpu/hotplug: detect SMT disabled by BIOS")
... the hotplug code attempted to detect when SMT was disabled by BIOS,
in which case it reported SMT as permanently disabled. However, that
code broke a virt hotplug scenario, where the guest is booted with only
primary CPU threads, and a sibling is brought online later.
The problem is that there doesn't seem to be a way to reliably
distinguish between the HW "SMT disabled by BIOS" case and the virt
"sibling not yet brought online" case. So the above-mentioned commit
was a bit misguided, as it permanently disabled SMT for both cases,
preventing future virt sibling hotplugs.
Going back and reviewing the original problems which were attempted to
be solved by that commit, when SMT was disabled in BIOS:
1) /sys/devices/system/cpu/smt/control showed "on" instead of
"notsupported"; and
2) vmx_vm_init() was incorrectly showing the L1TF_MSG_SMT warning.
I'd propose that we instead consider #1 above to not actually be a
problem. Because, at least in the virt case, it's possible that SMT
wasn't disabled by BIOS and a sibling thread could be brought online
later. So it makes sense to just always default the smt control to "on"
to allow for that possibility (assuming cpuid indicates that the CPU
supports SMT).
The real problem is #2, which has a simple fix: change vmx_vm_init() to
query the actual current SMT state -- i.e., whether any siblings are
currently online -- instead of looking at the SMT "control" sysfs value.
So fix it by:
a) reverting the original "fix" and its followup fix:
73d5e2b47264 ("cpu/hotplug: detect SMT disabled by BIOS")
bc2d8d262cba ("cpu/hotplug: Fix SMT supported evaluation")
and
b) changing vmx_vm_init() to query the actual current SMT state --
instead of the sysfs control value -- to determine whether the L1TF
warning is needed. This also requires the 'sched_smt_present'
variable to exported, instead of 'cpu_smt_control'.
Fixes: 73d5e2b47264 ("cpu/hotplug: detect SMT disabled by BIOS")
Reported-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Joe Mario <jmario@redhat.com>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: kvm@vger.kernel.org
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/e3a85d585da28cc333ecbc1e78ee9216e6da9396.1548794349.git.jpoimboe@redhat.com
2019-01-30 13:13:58 +00:00
cpu_smt_check_topology ( ) ;
2018-07-13 14:23:24 +00:00
2016-10-24 17:38:43 +00:00
if ( ! IS_ENABLED ( CONFIG_SMP ) ) {
pr_info ( " CPU: " ) ;
print_cpu_info ( & boot_cpu_data ) ;
}
2018-04-26 02:04:18 +00:00
/*
* Read the SPEC_CTRL MSR to account for reserved bits which may
2018-04-26 02:04:24 +00:00
* have unknown values . AMD64_LS_CFG MSR is cached in the early AMD
* init code as it is not enumerated and depends on the family .
2018-04-26 02:04:18 +00:00
*/
2022-11-28 15:31:48 +00:00
if ( cpu_feature_enabled ( X86_FEATURE_MSR_SPEC_CTRL ) ) {
2018-04-26 02:04:18 +00:00
rdmsrl ( MSR_IA32_SPEC_CTRL , x86_spec_ctrl_base ) ;
2022-11-28 15:31:48 +00:00
/*
* Previously running kernel ( kexec ) , may have some controls
* turned ON . Clear them and let the mitigations setup below
* rediscover them based on configuration .
*/
x86_spec_ctrl_base & = ~ SPEC_CTRL_MITIGATIONS_MASK ;
}
x86/speculation: Enable Spectre v1 swapgs mitigations
The previous commit added macro calls in the entry code which mitigate the
Spectre v1 swapgs issue if the X86_FEATURE_FENCE_SWAPGS_* features are
enabled. Enable those features where applicable.
The mitigations may be disabled with "nospectre_v1" or "mitigations=off".
There are different features which can affect the risk of attack:
- When FSGSBASE is enabled, unprivileged users are able to place any
value in GS, using the wrgsbase instruction. This means they can
write a GS value which points to any value in kernel space, which can
be useful with the following gadget in an interrupt/exception/NMI
handler:
if (coming from user space)
swapgs
mov %gs:<percpu_offset>, %reg1
// dependent load or store based on the value of %reg
// for example: mov %(reg1), %reg2
If an interrupt is coming from user space, and the entry code
speculatively skips the swapgs (due to user branch mistraining), it
may speculatively execute the GS-based load and a subsequent dependent
load or store, exposing the kernel data to an L1 side channel leak.
Note that, on Intel, a similar attack exists in the above gadget when
coming from kernel space, if the swapgs gets speculatively executed to
switch back to the user GS. On AMD, this variant isn't possible
because swapgs is serializing with respect to future GS-based
accesses.
NOTE: The FSGSBASE patch set hasn't been merged yet, so the above case
doesn't exist quite yet.
- When FSGSBASE is disabled, the issue is mitigated somewhat because
unprivileged users must use prctl(ARCH_SET_GS) to set GS, which
restricts GS values to user space addresses only. That means the
gadget would need an additional step, since the target kernel address
needs to be read from user space first. Something like:
if (coming from user space)
swapgs
mov %gs:<percpu_offset>, %reg1
mov (%reg1), %reg2
// dependent load or store based on the value of %reg2
// for example: mov %(reg2), %reg3
It's difficult to audit for this gadget in all the handlers, so while
there are no known instances of it, it's entirely possible that it
exists somewhere (or could be introduced in the future). Without
tooling to analyze all such code paths, consider it vulnerable.
Effects of SMAP on the !FSGSBASE case:
- If SMAP is enabled, and the CPU reports RDCL_NO (i.e., not
susceptible to Meltdown), the kernel is prevented from speculatively
reading user space memory, even L1 cached values. This effectively
disables the !FSGSBASE attack vector.
- If SMAP is enabled, but the CPU *is* susceptible to Meltdown, SMAP
still prevents the kernel from speculatively reading user space
memory. But it does *not* prevent the kernel from reading the
user value from L1, if it has already been cached. This is probably
only a small hurdle for an attacker to overcome.
Thanks to Dave Hansen for contributing the speculative_smap() function.
Thanks to Andrew Cooper for providing the inside scoop on whether swapgs
is serializing on AMD.
[ tglx: Fixed the USER fence decision and polished the comment as suggested
by Dave Hansen ]
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Dave Hansen <dave.hansen@intel.com>
2019-07-08 16:52:26 +00:00
/* Select the proper CPU mitigations before patching alternatives: */
spectre_v1_select_mitigation ( ) ;
2022-06-14 21:15:56 +00:00
spectre_v2_select_mitigation ( ) ;
/*
* retbleed_select_mitigation ( ) relies on the state set by
* spectre_v2_select_mitigation ( ) ; specifically it wants to know about
* spectre_v2 = ibrs .
*/
2022-06-14 21:15:50 +00:00
retbleed_select_mitigation ( ) ;
/*
2022-06-14 21:15:56 +00:00
* spectre_v2_user_select_mitigation ( ) relies on the state set by
2022-06-14 21:15:50 +00:00
* retbleed_select_mitigation ( ) ; specifically the STIBP selection is
x86/bugs: Enable STIBP for IBPB mitigated RETBleed
AMD's "Technical Guidance for Mitigating Branch Type Confusion,
Rev. 1.0 2022-07-12" whitepaper, under section 6.1.2 "IBPB On
Privileged Mode Entry / SMT Safety" says:
Similar to the Jmp2Ret mitigation, if the code on the sibling thread
cannot be trusted, software should set STIBP to 1 or disable SMT to
ensure SMT safety when using this mitigation.
So, like already being done for retbleed=unret, and now also for
retbleed=ibpb, force STIBP on machines that have it, and report its SMT
vulnerability status accordingly.
[ bp: Remove the "we" and remove "[AMD]" applicability parameter which
doesn't work here. ]
Fixes: 3ebc17006888 ("x86/bugs: Add retbleed=ibpb")
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: stable@vger.kernel.org # 5.10, 5.15, 5.19
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
Link: https://lore.kernel.org/r/20220804192201.439596-1-kim.phillips@amd.com
2022-08-08 14:32:33 +00:00
* forced for UNRET or IBPB .
2022-06-14 21:15:50 +00:00
*/
2022-06-14 21:15:56 +00:00
spectre_v2_user_select_mitigation ( ) ;
2018-04-26 02:04:21 +00:00
ssb_select_mitigation ( ) ;
2018-06-13 22:48:26 +00:00
l1tf_select_mitigation ( ) ;
2022-05-20 03:30:12 +00:00
md_clear_select_mitigation ( ) ;
2020-04-16 15:54:04 +00:00
srbds_select_mitigation ( ) ;
2021-04-26 19:42:30 +00:00
l1d_flush_select_mitigation ( ) ;
2019-02-18 21:04:08 +00:00
2019-04-02 15:00:14 +00:00
arch_smt_update ( ) ;
2016-10-24 17:38:43 +00:00
# ifdef CONFIG_X86_32
2013-04-08 15:57:44 +00:00
/*
* Check whether we are able to run this kernel safely on SMP .
*
* - i386 is no longer supported .
* - In order to run on anything without a TSC , we need to be
* compiled for a i486 .
*/
if ( boot_cpu_data . x86 < 4 )
panic ( " Kernel requires i486+ for 'invlpg' and other features " ) ;
2008-05-17 20:48:13 +00:00
init_utsname ( ) - > machine [ 1 ] =
' 0 ' + ( boot_cpu_data . x86 > 6 ? 6 : boot_cpu_data . x86 ) ;
2007-05-02 17:27:12 +00:00
alternative_instructions ( ) ;
2012-08-24 21:13:02 +00:00
2015-04-22 11:44:25 +00:00
fpu__init_check_bugs ( ) ;
2016-10-24 17:38:43 +00:00
# else /* CONFIG_X86_64 */
alternative_instructions ( ) ;
/*
* Make sure the first 2 MB area is not mapped by huge pages
* There are typically fixed size MTRRs in there and overlapping
* MTRRs into large pages causes slow downs .
*
* Right now we don ' t do that with gbpages because there seems
* very little benefit for that case .
*/
if ( ! direct_gbpages )
set_memory_4k ( ( unsigned long ) __va ( 0 ) , 1 ) ;
# endif
2007-05-02 17:27:12 +00:00
}
2018-01-07 21:48:01 +00:00
2022-06-14 21:16:13 +00:00
/*
KVM: SVM: move MSR_IA32_SPEC_CTRL save/restore to assembly
Restoration of the host IA32_SPEC_CTRL value is probably too late
with respect to the return thunk training sequence.
With respect to the user/kernel boundary, AMD says, "If software chooses
to toggle STIBP (e.g., set STIBP on kernel entry, and clear it on kernel
exit), software should set STIBP to 1 before executing the return thunk
training sequence." I assume the same requirements apply to the guest/host
boundary. The return thunk training sequence is in vmenter.S, quite close
to the VM-exit. On hosts without V_SPEC_CTRL, however, the host's
IA32_SPEC_CTRL value is not restored until much later.
To avoid this, move the restoration of host SPEC_CTRL to assembly and,
for consistency, move the restoration of the guest SPEC_CTRL as well.
This is not particularly difficult, apart from some care to cover both
32- and 64-bit, and to share code between SEV-ES and normal vmentry.
Cc: stable@vger.kernel.org
Fixes: a149180fbcf3 ("x86: Add magic AMD return-thunk")
Suggested-by: Jim Mattson <jmattson@google.com>
Reviewed-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-09-30 18:24:40 +00:00
* NOTE : This function is * only * called for SVM , since Intel uses
* MSR_IA32_SPEC_CTRL for SSBD .
2022-06-14 21:16:13 +00:00
*/
2018-05-11 22:14:51 +00:00
void
2022-09-30 18:48:24 +00:00
x86_virt_spec_ctrl ( u64 guest_virt_spec_ctrl , bool setguest )
2018-04-26 02:04:19 +00:00
{
KVM: SVM: move MSR_IA32_SPEC_CTRL save/restore to assembly
Restoration of the host IA32_SPEC_CTRL value is probably too late
with respect to the return thunk training sequence.
With respect to the user/kernel boundary, AMD says, "If software chooses
to toggle STIBP (e.g., set STIBP on kernel entry, and clear it on kernel
exit), software should set STIBP to 1 before executing the return thunk
training sequence." I assume the same requirements apply to the guest/host
boundary. The return thunk training sequence is in vmenter.S, quite close
to the VM-exit. On hosts without V_SPEC_CTRL, however, the host's
IA32_SPEC_CTRL value is not restored until much later.
To avoid this, move the restoration of host SPEC_CTRL to assembly and,
for consistency, move the restoration of the guest SPEC_CTRL as well.
This is not particularly difficult, apart from some care to cover both
32- and 64-bit, and to share code between SEV-ES and normal vmentry.
Cc: stable@vger.kernel.org
Fixes: a149180fbcf3 ("x86: Add magic AMD return-thunk")
Suggested-by: Jim Mattson <jmattson@google.com>
Reviewed-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-09-30 18:24:40 +00:00
u64 guestval , hostval ;
2018-05-11 22:14:51 +00:00
struct thread_info * ti = current_thread_info ( ) ;
2018-04-29 13:21:42 +00:00
2018-05-10 18:42:48 +00:00
/*
* If SSBD is not handled in MSR_SPEC_CTRL on AMD , update
* MSR_AMD64_L2_CFG or MSR_VIRT_SPEC_CTRL if supported .
*/
if ( ! static_cpu_has ( X86_FEATURE_LS_CFG_SSBD ) & &
! static_cpu_has ( X86_FEATURE_VIRT_SSBD ) )
return ;
/*
* If the host has SSBD mitigation enabled , force it in the host ' s
* virtual MSR value . If its not permanently enabled , evaluate
* current ' s TIF_SSBD thread flag .
*/
if ( static_cpu_has ( X86_FEATURE_SPEC_STORE_BYPASS_DISABLE ) )
hostval = SPEC_CTRL_SSBD ;
else
hostval = ssbd_tif_to_spec_ctrl ( ti - > flags ) ;
/* Sanitize the guest value */
guestval = guest_virt_spec_ctrl & SPEC_CTRL_SSBD ;
if ( hostval ! = guestval ) {
unsigned long tif ;
tif = setguest ? ssbd_spec_ctrl_to_tif ( guestval ) :
ssbd_spec_ctrl_to_tif ( hostval ) ;
2018-11-25 18:33:34 +00:00
speculation_ctrl_update ( tif ) ;
2018-05-10 18:42:48 +00:00
}
2018-04-26 02:04:19 +00:00
}
2018-05-11 22:14:51 +00:00
EXPORT_SYMBOL_GPL ( x86_virt_spec_ctrl ) ;
2018-04-26 02:04:19 +00:00
2018-05-09 19:41:38 +00:00
static void x86_amd_ssb_disable ( void )
2018-04-26 02:04:24 +00:00
{
2018-05-09 19:41:38 +00:00
u64 msrval = x86_amd_ls_cfg_base | x86_amd_ls_cfg_ssbd_mask ;
2018-04-26 02:04:24 +00:00
2018-05-17 15:09:18 +00:00
if ( boot_cpu_has ( X86_FEATURE_VIRT_SSBD ) )
wrmsrl ( MSR_AMD64_VIRT_SPEC_CTRL , SPEC_CTRL_SSBD ) ;
else if ( boot_cpu_has ( X86_FEATURE_LS_CFG_SSBD ) )
2018-04-26 02:04:24 +00:00
wrmsrl ( MSR_AMD64_LS_CFG , msrval ) ;
}
2019-02-18 21:04:08 +00:00
# undef pr_fmt
# define pr_fmt(fmt) "MDS: " fmt
2019-04-12 21:50:57 +00:00
/* Default mitigation for MDS-affected CPUs */
2019-02-18 21:04:08 +00:00
static enum mds_mitigations mds_mitigation __ro_after_init = MDS_MITIGATION_FULL ;
2019-04-02 14:59:33 +00:00
static bool mds_nosmt __ro_after_init = false ;
2019-02-18 21:04:08 +00:00
static const char * const mds_strings [ ] = {
[ MDS_MITIGATION_OFF ] = " Vulnerable " ,
2019-02-20 08:40:40 +00:00
[ MDS_MITIGATION_FULL ] = " Mitigation: Clear CPU buffers " ,
[ MDS_MITIGATION_VMWERV ] = " Vulnerable: Clear CPU buffers attempted, no microcode " ,
2019-02-18 21:04:08 +00:00
} ;
static void __init mds_select_mitigation ( void )
{
2019-04-17 21:39:02 +00:00
if ( ! boot_cpu_has_bug ( X86_BUG_MDS ) | | cpu_mitigations_off ( ) ) {
2019-02-18 21:04:08 +00:00
mds_mitigation = MDS_MITIGATION_OFF ;
return ;
}
if ( mds_mitigation = = MDS_MITIGATION_FULL ) {
2019-02-20 08:40:40 +00:00
if ( ! boot_cpu_has ( X86_FEATURE_MD_CLEAR ) )
mds_mitigation = MDS_MITIGATION_VMWERV ;
2019-04-02 14:59:33 +00:00
2019-02-20 08:40:40 +00:00
static_branch_enable ( & mds_user_clear ) ;
2019-04-02 14:59:33 +00:00
2019-04-17 21:39:02 +00:00
if ( ! boot_cpu_has ( X86_BUG_MSBDS_ONLY ) & &
( mds_nosmt | | cpu_mitigations_auto_nosmt ( ) ) )
2019-04-02 14:59:33 +00:00
cpu_smt_disable ( false ) ;
2019-02-18 21:04:08 +00:00
}
2019-11-15 16:14:45 +00:00
}
2019-02-18 21:04:08 +00:00
static int __init mds_cmdline ( char * str )
{
if ( ! boot_cpu_has_bug ( X86_BUG_MDS ) )
return 0 ;
if ( ! str )
return - EINVAL ;
if ( ! strcmp ( str , " off " ) )
mds_mitigation = MDS_MITIGATION_OFF ;
else if ( ! strcmp ( str , " full " ) )
mds_mitigation = MDS_MITIGATION_FULL ;
2019-04-02 14:59:33 +00:00
else if ( ! strcmp ( str , " full,nosmt " ) ) {
mds_mitigation = MDS_MITIGATION_FULL ;
mds_nosmt = true ;
}
2019-02-18 21:04:08 +00:00
return 0 ;
}
early_param ( " mds " , mds_cmdline ) ;
2019-10-23 09:30:45 +00:00
# undef pr_fmt
# define pr_fmt(fmt) "TAA: " fmt
2019-11-12 20:58:57 +00:00
enum taa_mitigations {
TAA_MITIGATION_OFF ,
TAA_MITIGATION_UCODE_NEEDED ,
TAA_MITIGATION_VERW ,
TAA_MITIGATION_TSX_DISABLED ,
} ;
2019-10-23 09:30:45 +00:00
/* Default mitigation for TAA-affected CPUs */
static enum taa_mitigations taa_mitigation __ro_after_init = TAA_MITIGATION_VERW ;
static bool taa_nosmt __ro_after_init ;
static const char * const taa_strings [ ] = {
[ TAA_MITIGATION_OFF ] = " Vulnerable " ,
[ TAA_MITIGATION_UCODE_NEEDED ] = " Vulnerable: Clear CPU buffers attempted, no microcode " ,
[ TAA_MITIGATION_VERW ] = " Mitigation: Clear CPU buffers " ,
[ TAA_MITIGATION_TSX_DISABLED ] = " Mitigation: TSX disabled " ,
} ;
static void __init taa_select_mitigation ( void )
{
u64 ia32_cap ;
if ( ! boot_cpu_has_bug ( X86_BUG_TAA ) ) {
taa_mitigation = TAA_MITIGATION_OFF ;
return ;
}
/* TSX previously disabled by tsx=off */
if ( ! boot_cpu_has ( X86_FEATURE_RTM ) ) {
taa_mitigation = TAA_MITIGATION_TSX_DISABLED ;
2022-05-20 03:28:10 +00:00
return ;
2019-10-23 09:30:45 +00:00
}
if ( cpu_mitigations_off ( ) ) {
taa_mitigation = TAA_MITIGATION_OFF ;
return ;
}
2019-11-15 16:14:44 +00:00
/*
* TAA mitigation via VERW is turned off if both
* tsx_async_abort = off and mds = off are specified .
*/
if ( taa_mitigation = = TAA_MITIGATION_OFF & &
mds_mitigation = = MDS_MITIGATION_OFF )
2022-05-20 03:28:10 +00:00
return ;
2019-10-23 09:30:45 +00:00
if ( boot_cpu_has ( X86_FEATURE_MD_CLEAR ) )
taa_mitigation = TAA_MITIGATION_VERW ;
else
taa_mitigation = TAA_MITIGATION_UCODE_NEEDED ;
/*
* VERW doesn ' t clear the CPU buffers when MD_CLEAR = 1 and MDS_NO = 1.
* A microcode update fixes this behavior to clear CPU buffers . It also
* adds support for MSR_IA32_TSX_CTRL which is enumerated by the
* ARCH_CAP_TSX_CTRL_MSR bit .
*
* On MDS_NO = 1 CPUs if ARCH_CAP_TSX_CTRL_MSR is not set , microcode
* update is required .
*/
ia32_cap = x86_read_arch_cap_msr ( ) ;
if ( ( ia32_cap & ARCH_CAP_MDS_NO ) & &
! ( ia32_cap & ARCH_CAP_TSX_CTRL_MSR ) )
taa_mitigation = TAA_MITIGATION_UCODE_NEEDED ;
/*
* TSX is enabled , select alternate mitigation for TAA which is
* the same as MDS . Enable MDS static branch to clear CPU buffers .
*
* For guests that can ' t determine whether the correct microcode is
* present on host , enable the mitigation for UCODE_NEEDED as well .
*/
static_branch_enable ( & mds_user_clear ) ;
if ( taa_nosmt | | cpu_mitigations_auto_nosmt ( ) )
cpu_smt_disable ( false ) ;
}
static int __init tsx_async_abort_parse_cmdline ( char * str )
{
if ( ! boot_cpu_has_bug ( X86_BUG_TAA ) )
return 0 ;
if ( ! str )
return - EINVAL ;
if ( ! strcmp ( str , " off " ) ) {
taa_mitigation = TAA_MITIGATION_OFF ;
} else if ( ! strcmp ( str , " full " ) ) {
taa_mitigation = TAA_MITIGATION_VERW ;
} else if ( ! strcmp ( str , " full,nosmt " ) ) {
taa_mitigation = TAA_MITIGATION_VERW ;
taa_nosmt = true ;
}
return 0 ;
}
early_param ( " tsx_async_abort " , tsx_async_abort_parse_cmdline ) ;
2022-05-20 03:29:11 +00:00
# undef pr_fmt
# define pr_fmt(fmt) "MMIO Stale Data: " fmt
enum mmio_mitigations {
MMIO_MITIGATION_OFF ,
MMIO_MITIGATION_UCODE_NEEDED ,
MMIO_MITIGATION_VERW ,
} ;
/* Default mitigation for Processor MMIO Stale Data vulnerabilities */
static enum mmio_mitigations mmio_mitigation __ro_after_init = MMIO_MITIGATION_VERW ;
static bool mmio_nosmt __ro_after_init = false ;
static const char * const mmio_strings [ ] = {
[ MMIO_MITIGATION_OFF ] = " Vulnerable " ,
[ MMIO_MITIGATION_UCODE_NEEDED ] = " Vulnerable: Clear CPU buffers attempted, no microcode " ,
[ MMIO_MITIGATION_VERW ] = " Mitigation: Clear CPU buffers " ,
} ;
static void __init mmio_select_mitigation ( void )
{
u64 ia32_cap ;
if ( ! boot_cpu_has_bug ( X86_BUG_MMIO_STALE_DATA ) | |
2022-08-03 21:41:32 +00:00
boot_cpu_has_bug ( X86_BUG_MMIO_UNKNOWN ) | |
cpu_mitigations_off ( ) ) {
2022-05-20 03:29:11 +00:00
mmio_mitigation = MMIO_MITIGATION_OFF ;
return ;
}
if ( mmio_mitigation = = MMIO_MITIGATION_OFF )
return ;
ia32_cap = x86_read_arch_cap_msr ( ) ;
/*
* Enable CPU buffer clear mitigation for host and VMM , if also affected
* by MDS or TAA . Otherwise , enable mitigation for VMM only .
*/
if ( boot_cpu_has_bug ( X86_BUG_MDS ) | | ( boot_cpu_has_bug ( X86_BUG_TAA ) & &
boot_cpu_has ( X86_FEATURE_RTM ) ) )
static_branch_enable ( & mds_user_clear ) ;
else
static_branch_enable ( & mmio_stale_data_clear ) ;
2022-05-20 03:31:12 +00:00
/*
* If Processor - MMIO - Stale - Data bug is present and Fill Buffer data can
* be propagated to uncore buffers , clearing the Fill buffers on idle
* is required irrespective of SMT state .
*/
if ( ! ( ia32_cap & ARCH_CAP_FBSDP_NO ) )
static_branch_enable ( & mds_idle_clear ) ;
2022-05-20 03:29:11 +00:00
/*
* Check if the system has the right microcode .
*
* CPU Fill buffer clear mitigation is enumerated by either an explicit
* FB_CLEAR or by the presence of both MD_CLEAR and L1D_FLUSH on MDS
* affected systems .
*/
if ( ( ia32_cap & ARCH_CAP_FB_CLEAR ) | |
( boot_cpu_has ( X86_FEATURE_MD_CLEAR ) & &
boot_cpu_has ( X86_FEATURE_FLUSH_L1D ) & &
! ( ia32_cap & ARCH_CAP_MDS_NO ) ) )
mmio_mitigation = MMIO_MITIGATION_VERW ;
else
mmio_mitigation = MMIO_MITIGATION_UCODE_NEEDED ;
if ( mmio_nosmt | | cpu_mitigations_auto_nosmt ( ) )
cpu_smt_disable ( false ) ;
}
static int __init mmio_stale_data_parse_cmdline ( char * str )
{
if ( ! boot_cpu_has_bug ( X86_BUG_MMIO_STALE_DATA ) )
return 0 ;
if ( ! str )
return - EINVAL ;
if ( ! strcmp ( str , " off " ) ) {
mmio_mitigation = MMIO_MITIGATION_OFF ;
} else if ( ! strcmp ( str , " full " ) ) {
mmio_mitigation = MMIO_MITIGATION_VERW ;
} else if ( ! strcmp ( str , " full,nosmt " ) ) {
mmio_mitigation = MMIO_MITIGATION_VERW ;
mmio_nosmt = true ;
}
return 0 ;
}
early_param ( " mmio_stale_data " , mmio_stale_data_parse_cmdline ) ;
2022-05-20 03:28:10 +00:00
# undef pr_fmt
# define pr_fmt(fmt) "" fmt
static void __init md_clear_update_mitigation ( void )
{
if ( cpu_mitigations_off ( ) )
return ;
if ( ! static_key_enabled ( & mds_user_clear ) )
goto out ;
/*
2022-05-20 03:29:11 +00:00
* mds_user_clear is now enabled . Update MDS , TAA and MMIO Stale Data
* mitigation , if necessary .
2022-05-20 03:28:10 +00:00
*/
if ( mds_mitigation = = MDS_MITIGATION_OFF & &
boot_cpu_has_bug ( X86_BUG_MDS ) ) {
mds_mitigation = MDS_MITIGATION_FULL ;
mds_select_mitigation ( ) ;
}
2022-05-20 03:29:11 +00:00
if ( taa_mitigation = = TAA_MITIGATION_OFF & &
boot_cpu_has_bug ( X86_BUG_TAA ) ) {
taa_mitigation = TAA_MITIGATION_VERW ;
taa_select_mitigation ( ) ;
}
if ( mmio_mitigation = = MMIO_MITIGATION_OFF & &
boot_cpu_has_bug ( X86_BUG_MMIO_STALE_DATA ) ) {
mmio_mitigation = MMIO_MITIGATION_VERW ;
mmio_select_mitigation ( ) ;
}
2022-05-20 03:28:10 +00:00
out :
if ( boot_cpu_has_bug ( X86_BUG_MDS ) )
pr_info ( " MDS: %s \n " , mds_strings [ mds_mitigation ] ) ;
if ( boot_cpu_has_bug ( X86_BUG_TAA ) )
pr_info ( " TAA: %s \n " , taa_strings [ taa_mitigation ] ) ;
2022-05-20 03:29:11 +00:00
if ( boot_cpu_has_bug ( X86_BUG_MMIO_STALE_DATA ) )
pr_info ( " MMIO Stale Data: %s \n " , mmio_strings [ mmio_mitigation ] ) ;
2022-08-03 21:41:32 +00:00
else if ( boot_cpu_has_bug ( X86_BUG_MMIO_UNKNOWN ) )
pr_info ( " MMIO Stale Data: Unknown: No mitigations \n " ) ;
2022-05-20 03:28:10 +00:00
}
2022-05-20 03:30:12 +00:00
static void __init md_clear_select_mitigation ( void )
{
mds_select_mitigation ( ) ;
taa_select_mitigation ( ) ;
mmio_select_mitigation ( ) ;
/*
* As MDS , TAA and MMIO Stale Data mitigations are inter - related , update
* and print their mitigation after MDS , TAA and MMIO Stale Data
* mitigation selection is done .
*/
md_clear_update_mitigation ( ) ;
}
2020-04-16 15:54:04 +00:00
# undef pr_fmt
# define pr_fmt(fmt) "SRBDS: " fmt
enum srbds_mitigations {
SRBDS_MITIGATION_OFF ,
SRBDS_MITIGATION_UCODE_NEEDED ,
SRBDS_MITIGATION_FULL ,
SRBDS_MITIGATION_TSX_OFF ,
SRBDS_MITIGATION_HYPERVISOR ,
} ;
static enum srbds_mitigations srbds_mitigation __ro_after_init = SRBDS_MITIGATION_FULL ;
static const char * const srbds_strings [ ] = {
[ SRBDS_MITIGATION_OFF ] = " Vulnerable " ,
[ SRBDS_MITIGATION_UCODE_NEEDED ] = " Vulnerable: No microcode " ,
[ SRBDS_MITIGATION_FULL ] = " Mitigation: Microcode " ,
[ SRBDS_MITIGATION_TSX_OFF ] = " Mitigation: TSX disabled " ,
[ SRBDS_MITIGATION_HYPERVISOR ] = " Unknown: Dependent on hypervisor status " ,
} ;
static bool srbds_off ;
void update_srbds_msr ( void )
{
u64 mcu_ctrl ;
if ( ! boot_cpu_has_bug ( X86_BUG_SRBDS ) )
return ;
if ( boot_cpu_has ( X86_FEATURE_HYPERVISOR ) )
return ;
if ( srbds_mitigation = = SRBDS_MITIGATION_UCODE_NEEDED )
return ;
2022-04-01 07:45:17 +00:00
/*
* A MDS_NO CPU for which SRBDS mitigation is not needed due to TSX
* being disabled and it hasn ' t received the SRBDS MSR microcode .
*/
if ( ! boot_cpu_has ( X86_FEATURE_SRBDS_CTRL ) )
return ;
2020-04-16 15:54:04 +00:00
rdmsrl ( MSR_IA32_MCU_OPT_CTRL , mcu_ctrl ) ;
switch ( srbds_mitigation ) {
case SRBDS_MITIGATION_OFF :
case SRBDS_MITIGATION_TSX_OFF :
mcu_ctrl | = RNGDS_MITG_DIS ;
break ;
case SRBDS_MITIGATION_FULL :
mcu_ctrl & = ~ RNGDS_MITG_DIS ;
break ;
default :
break ;
}
wrmsrl ( MSR_IA32_MCU_OPT_CTRL , mcu_ctrl ) ;
}
static void __init srbds_select_mitigation ( void )
{
u64 ia32_cap ;
if ( ! boot_cpu_has_bug ( X86_BUG_SRBDS ) )
return ;
/*
2022-05-20 03:33:13 +00:00
* Check to see if this is one of the MDS_NO systems supporting TSX that
* are only exposed to SRBDS when TSX is enabled or when CPU is affected
* by Processor MMIO Stale Data vulnerability .
2020-04-16 15:54:04 +00:00
*/
ia32_cap = x86_read_arch_cap_msr ( ) ;
2022-05-20 03:33:13 +00:00
if ( ( ia32_cap & ARCH_CAP_MDS_NO ) & & ! boot_cpu_has ( X86_FEATURE_RTM ) & &
! boot_cpu_has_bug ( X86_BUG_MMIO_STALE_DATA ) )
2020-04-16 15:54:04 +00:00
srbds_mitigation = SRBDS_MITIGATION_TSX_OFF ;
else if ( boot_cpu_has ( X86_FEATURE_HYPERVISOR ) )
srbds_mitigation = SRBDS_MITIGATION_HYPERVISOR ;
else if ( ! boot_cpu_has ( X86_FEATURE_SRBDS_CTRL ) )
srbds_mitigation = SRBDS_MITIGATION_UCODE_NEEDED ;
else if ( cpu_mitigations_off ( ) | | srbds_off )
srbds_mitigation = SRBDS_MITIGATION_OFF ;
update_srbds_msr ( ) ;
pr_info ( " %s \n " , srbds_strings [ srbds_mitigation ] ) ;
}
static int __init srbds_parse_cmdline ( char * str )
{
if ( ! str )
return - EINVAL ;
if ( ! boot_cpu_has_bug ( X86_BUG_SRBDS ) )
return 0 ;
srbds_off = ! strcmp ( str , " off " ) ;
return 0 ;
}
early_param ( " srbds " , srbds_parse_cmdline ) ;
2021-04-26 19:42:30 +00:00
# undef pr_fmt
# define pr_fmt(fmt) "L1D Flush : " fmt
enum l1d_flush_mitigations {
L1D_FLUSH_OFF = 0 ,
L1D_FLUSH_ON ,
} ;
static enum l1d_flush_mitigations l1d_flush_mitigation __initdata = L1D_FLUSH_OFF ;
static void __init l1d_flush_select_mitigation ( void )
{
if ( ! l1d_flush_mitigation | | ! boot_cpu_has ( X86_FEATURE_FLUSH_L1D ) )
return ;
static_branch_enable ( & switch_mm_cond_l1d_flush ) ;
pr_info ( " Conditional flush on switch_mm() enabled \n " ) ;
}
static int __init l1d_flush_parse_cmdline ( char * str )
{
if ( ! strcmp ( str , " on " ) )
l1d_flush_mitigation = L1D_FLUSH_ON ;
return 0 ;
}
early_param ( " l1d_flush " , l1d_flush_parse_cmdline ) ;
x86/speculation: Enable Spectre v1 swapgs mitigations
The previous commit added macro calls in the entry code which mitigate the
Spectre v1 swapgs issue if the X86_FEATURE_FENCE_SWAPGS_* features are
enabled. Enable those features where applicable.
The mitigations may be disabled with "nospectre_v1" or "mitigations=off".
There are different features which can affect the risk of attack:
- When FSGSBASE is enabled, unprivileged users are able to place any
value in GS, using the wrgsbase instruction. This means they can
write a GS value which points to any value in kernel space, which can
be useful with the following gadget in an interrupt/exception/NMI
handler:
if (coming from user space)
swapgs
mov %gs:<percpu_offset>, %reg1
// dependent load or store based on the value of %reg
// for example: mov %(reg1), %reg2
If an interrupt is coming from user space, and the entry code
speculatively skips the swapgs (due to user branch mistraining), it
may speculatively execute the GS-based load and a subsequent dependent
load or store, exposing the kernel data to an L1 side channel leak.
Note that, on Intel, a similar attack exists in the above gadget when
coming from kernel space, if the swapgs gets speculatively executed to
switch back to the user GS. On AMD, this variant isn't possible
because swapgs is serializing with respect to future GS-based
accesses.
NOTE: The FSGSBASE patch set hasn't been merged yet, so the above case
doesn't exist quite yet.
- When FSGSBASE is disabled, the issue is mitigated somewhat because
unprivileged users must use prctl(ARCH_SET_GS) to set GS, which
restricts GS values to user space addresses only. That means the
gadget would need an additional step, since the target kernel address
needs to be read from user space first. Something like:
if (coming from user space)
swapgs
mov %gs:<percpu_offset>, %reg1
mov (%reg1), %reg2
// dependent load or store based on the value of %reg2
// for example: mov %(reg2), %reg3
It's difficult to audit for this gadget in all the handlers, so while
there are no known instances of it, it's entirely possible that it
exists somewhere (or could be introduced in the future). Without
tooling to analyze all such code paths, consider it vulnerable.
Effects of SMAP on the !FSGSBASE case:
- If SMAP is enabled, and the CPU reports RDCL_NO (i.e., not
susceptible to Meltdown), the kernel is prevented from speculatively
reading user space memory, even L1 cached values. This effectively
disables the !FSGSBASE attack vector.
- If SMAP is enabled, but the CPU *is* susceptible to Meltdown, SMAP
still prevents the kernel from speculatively reading user space
memory. But it does *not* prevent the kernel from reading the
user value from L1, if it has already been cached. This is probably
only a small hurdle for an attacker to overcome.
Thanks to Dave Hansen for contributing the speculative_smap() function.
Thanks to Andrew Cooper for providing the inside scoop on whether swapgs
is serializing on AMD.
[ tglx: Fixed the USER fence decision and polished the comment as suggested
by Dave Hansen ]
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Dave Hansen <dave.hansen@intel.com>
2019-07-08 16:52:26 +00:00
# undef pr_fmt
# define pr_fmt(fmt) "Spectre V1 : " fmt
enum spectre_v1_mitigation {
SPECTRE_V1_MITIGATION_NONE ,
SPECTRE_V1_MITIGATION_AUTO ,
} ;
static enum spectre_v1_mitigation spectre_v1_mitigation __ro_after_init =
SPECTRE_V1_MITIGATION_AUTO ;
static const char * const spectre_v1_strings [ ] = {
[ SPECTRE_V1_MITIGATION_NONE ] = " Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers " ,
[ SPECTRE_V1_MITIGATION_AUTO ] = " Mitigation: usercopy/swapgs barriers and __user pointer sanitization " ,
} ;
/*
* Does SMAP provide full mitigation against speculative kernel access to
* userspace ?
*/
static bool smap_works_speculatively ( void )
{
if ( ! boot_cpu_has ( X86_FEATURE_SMAP ) )
return false ;
/*
* On CPUs which are vulnerable to Meltdown , SMAP does not
* prevent speculative access to user data in the L1 cache .
* Consider SMAP to be non - functional as a mitigation on these
* CPUs .
*/
if ( boot_cpu_has ( X86_BUG_CPU_MELTDOWN ) )
return false ;
return true ;
}
static void __init spectre_v1_select_mitigation ( void )
{
if ( ! boot_cpu_has_bug ( X86_BUG_SPECTRE_V1 ) | | cpu_mitigations_off ( ) ) {
spectre_v1_mitigation = SPECTRE_V1_MITIGATION_NONE ;
return ;
}
if ( spectre_v1_mitigation = = SPECTRE_V1_MITIGATION_AUTO ) {
/*
* With Spectre v1 , a user can speculatively control either
* path of a conditional swapgs with a user - controlled GS
* value . The mitigation is to add lfences to both code paths .
*
* If FSGSBASE is enabled , the user can put a kernel address in
* GS , in which case SMAP provides no protection .
*
* If FSGSBASE is disabled , the user can only put a user space
* address in GS . That makes an attack harder , but still
* possible if there ' s no SMAP protection .
*/
2020-05-28 20:13:54 +00:00
if ( boot_cpu_has ( X86_FEATURE_FSGSBASE ) | |
! smap_works_speculatively ( ) ) {
x86/speculation: Enable Spectre v1 swapgs mitigations
The previous commit added macro calls in the entry code which mitigate the
Spectre v1 swapgs issue if the X86_FEATURE_FENCE_SWAPGS_* features are
enabled. Enable those features where applicable.
The mitigations may be disabled with "nospectre_v1" or "mitigations=off".
There are different features which can affect the risk of attack:
- When FSGSBASE is enabled, unprivileged users are able to place any
value in GS, using the wrgsbase instruction. This means they can
write a GS value which points to any value in kernel space, which can
be useful with the following gadget in an interrupt/exception/NMI
handler:
if (coming from user space)
swapgs
mov %gs:<percpu_offset>, %reg1
// dependent load or store based on the value of %reg
// for example: mov %(reg1), %reg2
If an interrupt is coming from user space, and the entry code
speculatively skips the swapgs (due to user branch mistraining), it
may speculatively execute the GS-based load and a subsequent dependent
load or store, exposing the kernel data to an L1 side channel leak.
Note that, on Intel, a similar attack exists in the above gadget when
coming from kernel space, if the swapgs gets speculatively executed to
switch back to the user GS. On AMD, this variant isn't possible
because swapgs is serializing with respect to future GS-based
accesses.
NOTE: The FSGSBASE patch set hasn't been merged yet, so the above case
doesn't exist quite yet.
- When FSGSBASE is disabled, the issue is mitigated somewhat because
unprivileged users must use prctl(ARCH_SET_GS) to set GS, which
restricts GS values to user space addresses only. That means the
gadget would need an additional step, since the target kernel address
needs to be read from user space first. Something like:
if (coming from user space)
swapgs
mov %gs:<percpu_offset>, %reg1
mov (%reg1), %reg2
// dependent load or store based on the value of %reg2
// for example: mov %(reg2), %reg3
It's difficult to audit for this gadget in all the handlers, so while
there are no known instances of it, it's entirely possible that it
exists somewhere (or could be introduced in the future). Without
tooling to analyze all such code paths, consider it vulnerable.
Effects of SMAP on the !FSGSBASE case:
- If SMAP is enabled, and the CPU reports RDCL_NO (i.e., not
susceptible to Meltdown), the kernel is prevented from speculatively
reading user space memory, even L1 cached values. This effectively
disables the !FSGSBASE attack vector.
- If SMAP is enabled, but the CPU *is* susceptible to Meltdown, SMAP
still prevents the kernel from speculatively reading user space
memory. But it does *not* prevent the kernel from reading the
user value from L1, if it has already been cached. This is probably
only a small hurdle for an attacker to overcome.
Thanks to Dave Hansen for contributing the speculative_smap() function.
Thanks to Andrew Cooper for providing the inside scoop on whether swapgs
is serializing on AMD.
[ tglx: Fixed the USER fence decision and polished the comment as suggested
by Dave Hansen ]
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Dave Hansen <dave.hansen@intel.com>
2019-07-08 16:52:26 +00:00
/*
* Mitigation can be provided from SWAPGS itself or
* PTI as the CR3 write in the Meltdown mitigation
* is serializing .
*
2019-07-17 19:18:59 +00:00
* If neither is there , mitigate with an LFENCE to
* stop speculation through swapgs .
x86/speculation: Enable Spectre v1 swapgs mitigations
The previous commit added macro calls in the entry code which mitigate the
Spectre v1 swapgs issue if the X86_FEATURE_FENCE_SWAPGS_* features are
enabled. Enable those features where applicable.
The mitigations may be disabled with "nospectre_v1" or "mitigations=off".
There are different features which can affect the risk of attack:
- When FSGSBASE is enabled, unprivileged users are able to place any
value in GS, using the wrgsbase instruction. This means they can
write a GS value which points to any value in kernel space, which can
be useful with the following gadget in an interrupt/exception/NMI
handler:
if (coming from user space)
swapgs
mov %gs:<percpu_offset>, %reg1
// dependent load or store based on the value of %reg
// for example: mov %(reg1), %reg2
If an interrupt is coming from user space, and the entry code
speculatively skips the swapgs (due to user branch mistraining), it
may speculatively execute the GS-based load and a subsequent dependent
load or store, exposing the kernel data to an L1 side channel leak.
Note that, on Intel, a similar attack exists in the above gadget when
coming from kernel space, if the swapgs gets speculatively executed to
switch back to the user GS. On AMD, this variant isn't possible
because swapgs is serializing with respect to future GS-based
accesses.
NOTE: The FSGSBASE patch set hasn't been merged yet, so the above case
doesn't exist quite yet.
- When FSGSBASE is disabled, the issue is mitigated somewhat because
unprivileged users must use prctl(ARCH_SET_GS) to set GS, which
restricts GS values to user space addresses only. That means the
gadget would need an additional step, since the target kernel address
needs to be read from user space first. Something like:
if (coming from user space)
swapgs
mov %gs:<percpu_offset>, %reg1
mov (%reg1), %reg2
// dependent load or store based on the value of %reg2
// for example: mov %(reg2), %reg3
It's difficult to audit for this gadget in all the handlers, so while
there are no known instances of it, it's entirely possible that it
exists somewhere (or could be introduced in the future). Without
tooling to analyze all such code paths, consider it vulnerable.
Effects of SMAP on the !FSGSBASE case:
- If SMAP is enabled, and the CPU reports RDCL_NO (i.e., not
susceptible to Meltdown), the kernel is prevented from speculatively
reading user space memory, even L1 cached values. This effectively
disables the !FSGSBASE attack vector.
- If SMAP is enabled, but the CPU *is* susceptible to Meltdown, SMAP
still prevents the kernel from speculatively reading user space
memory. But it does *not* prevent the kernel from reading the
user value from L1, if it has already been cached. This is probably
only a small hurdle for an attacker to overcome.
Thanks to Dave Hansen for contributing the speculative_smap() function.
Thanks to Andrew Cooper for providing the inside scoop on whether swapgs
is serializing on AMD.
[ tglx: Fixed the USER fence decision and polished the comment as suggested
by Dave Hansen ]
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Dave Hansen <dave.hansen@intel.com>
2019-07-08 16:52:26 +00:00
*/
2019-07-17 19:18:59 +00:00
if ( boot_cpu_has_bug ( X86_BUG_SWAPGS ) & &
! boot_cpu_has ( X86_FEATURE_PTI ) )
x86/speculation: Enable Spectre v1 swapgs mitigations
The previous commit added macro calls in the entry code which mitigate the
Spectre v1 swapgs issue if the X86_FEATURE_FENCE_SWAPGS_* features are
enabled. Enable those features where applicable.
The mitigations may be disabled with "nospectre_v1" or "mitigations=off".
There are different features which can affect the risk of attack:
- When FSGSBASE is enabled, unprivileged users are able to place any
value in GS, using the wrgsbase instruction. This means they can
write a GS value which points to any value in kernel space, which can
be useful with the following gadget in an interrupt/exception/NMI
handler:
if (coming from user space)
swapgs
mov %gs:<percpu_offset>, %reg1
// dependent load or store based on the value of %reg
// for example: mov %(reg1), %reg2
If an interrupt is coming from user space, and the entry code
speculatively skips the swapgs (due to user branch mistraining), it
may speculatively execute the GS-based load and a subsequent dependent
load or store, exposing the kernel data to an L1 side channel leak.
Note that, on Intel, a similar attack exists in the above gadget when
coming from kernel space, if the swapgs gets speculatively executed to
switch back to the user GS. On AMD, this variant isn't possible
because swapgs is serializing with respect to future GS-based
accesses.
NOTE: The FSGSBASE patch set hasn't been merged yet, so the above case
doesn't exist quite yet.
- When FSGSBASE is disabled, the issue is mitigated somewhat because
unprivileged users must use prctl(ARCH_SET_GS) to set GS, which
restricts GS values to user space addresses only. That means the
gadget would need an additional step, since the target kernel address
needs to be read from user space first. Something like:
if (coming from user space)
swapgs
mov %gs:<percpu_offset>, %reg1
mov (%reg1), %reg2
// dependent load or store based on the value of %reg2
// for example: mov %(reg2), %reg3
It's difficult to audit for this gadget in all the handlers, so while
there are no known instances of it, it's entirely possible that it
exists somewhere (or could be introduced in the future). Without
tooling to analyze all such code paths, consider it vulnerable.
Effects of SMAP on the !FSGSBASE case:
- If SMAP is enabled, and the CPU reports RDCL_NO (i.e., not
susceptible to Meltdown), the kernel is prevented from speculatively
reading user space memory, even L1 cached values. This effectively
disables the !FSGSBASE attack vector.
- If SMAP is enabled, but the CPU *is* susceptible to Meltdown, SMAP
still prevents the kernel from speculatively reading user space
memory. But it does *not* prevent the kernel from reading the
user value from L1, if it has already been cached. This is probably
only a small hurdle for an attacker to overcome.
Thanks to Dave Hansen for contributing the speculative_smap() function.
Thanks to Andrew Cooper for providing the inside scoop on whether swapgs
is serializing on AMD.
[ tglx: Fixed the USER fence decision and polished the comment as suggested
by Dave Hansen ]
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Dave Hansen <dave.hansen@intel.com>
2019-07-08 16:52:26 +00:00
setup_force_cpu_cap ( X86_FEATURE_FENCE_SWAPGS_USER ) ;
/*
* Enable lfences in the kernel entry ( non - swapgs )
* paths , to prevent user entry from speculatively
* skipping swapgs .
*/
setup_force_cpu_cap ( X86_FEATURE_FENCE_SWAPGS_KERNEL ) ;
}
}
pr_info ( " %s \n " , spectre_v1_strings [ spectre_v1_mitigation ] ) ;
}
static int __init nospectre_v1_cmdline ( char * str )
{
spectre_v1_mitigation = SPECTRE_V1_MITIGATION_NONE ;
return 0 ;
}
early_param ( " nospectre_v1 " , nospectre_v1_cmdline ) ;
2023-02-25 00:11:31 +00:00
enum spectre_v2_mitigation spectre_v2_enabled __ro_after_init = SPECTRE_V2_NONE ;
2022-06-24 11:48:58 +00:00
2022-06-14 21:15:50 +00:00
# undef pr_fmt
# define pr_fmt(fmt) "RETBleed: " fmt
enum retbleed_mitigation {
RETBLEED_MITIGATION_NONE ,
RETBLEED_MITIGATION_UNRET ,
2022-06-14 21:16:02 +00:00
RETBLEED_MITIGATION_IBPB ,
2022-06-24 11:48:58 +00:00
RETBLEED_MITIGATION_IBRS ,
RETBLEED_MITIGATION_EIBRS ,
2022-09-15 11:11:38 +00:00
RETBLEED_MITIGATION_STUFF ,
2022-06-14 21:15:50 +00:00
} ;
enum retbleed_mitigation_cmd {
RETBLEED_CMD_OFF ,
RETBLEED_CMD_AUTO ,
RETBLEED_CMD_UNRET ,
2022-06-14 21:16:02 +00:00
RETBLEED_CMD_IBPB ,
2022-09-15 11:11:38 +00:00
RETBLEED_CMD_STUFF ,
2022-06-14 21:15:50 +00:00
} ;
2022-07-14 07:29:39 +00:00
static const char * const retbleed_strings [ ] = {
2022-06-14 21:15:50 +00:00
[ RETBLEED_MITIGATION_NONE ] = " Vulnerable " ,
[ RETBLEED_MITIGATION_UNRET ] = " Mitigation: untrained return thunk " ,
2022-06-14 21:16:02 +00:00
[ RETBLEED_MITIGATION_IBPB ] = " Mitigation: IBPB " ,
2022-06-24 11:48:58 +00:00
[ RETBLEED_MITIGATION_IBRS ] = " Mitigation: IBRS " ,
[ RETBLEED_MITIGATION_EIBRS ] = " Mitigation: Enhanced IBRS " ,
2022-09-15 11:11:38 +00:00
[ RETBLEED_MITIGATION_STUFF ] = " Mitigation: Stuffing " ,
2022-06-14 21:15:50 +00:00
} ;
static enum retbleed_mitigation retbleed_mitigation __ro_after_init =
RETBLEED_MITIGATION_NONE ;
static enum retbleed_mitigation_cmd retbleed_cmd __ro_after_init =
RETBLEED_CMD_AUTO ;
2022-06-14 21:15:51 +00:00
static int __ro_after_init retbleed_nosmt = false ;
2022-06-14 21:15:50 +00:00
static int __init retbleed_parse_cmdline ( char * str )
{
if ( ! str )
return - EINVAL ;
2022-06-14 21:15:51 +00:00
while ( str ) {
char * next = strchr ( str , ' , ' ) ;
if ( next ) {
* next = 0 ;
next + + ;
}
if ( ! strcmp ( str , " off " ) ) {
retbleed_cmd = RETBLEED_CMD_OFF ;
} else if ( ! strcmp ( str , " auto " ) ) {
retbleed_cmd = RETBLEED_CMD_AUTO ;
} else if ( ! strcmp ( str , " unret " ) ) {
retbleed_cmd = RETBLEED_CMD_UNRET ;
2022-06-14 21:16:02 +00:00
} else if ( ! strcmp ( str , " ibpb " ) ) {
retbleed_cmd = RETBLEED_CMD_IBPB ;
2022-09-15 11:11:38 +00:00
} else if ( ! strcmp ( str , " stuff " ) ) {
retbleed_cmd = RETBLEED_CMD_STUFF ;
2022-06-14 21:15:51 +00:00
} else if ( ! strcmp ( str , " nosmt " ) ) {
retbleed_nosmt = true ;
2022-10-17 14:41:20 +00:00
} else if ( ! strcmp ( str , " force " ) ) {
setup_force_cpu_bug ( X86_BUG_RETBLEED ) ;
2022-06-14 21:15:51 +00:00
} else {
pr_err ( " Ignoring unknown retbleed option (%s). " , str ) ;
}
str = next ;
}
2022-06-14 21:15:50 +00:00
return 0 ;
}
early_param ( " retbleed " , retbleed_parse_cmdline ) ;
# define RETBLEED_UNTRAIN_MSG "WARNING: BTB untrained return thunk mitigation is only effective on AMD / Hygon!\n"
2022-06-24 11:48:58 +00:00
# define RETBLEED_INTEL_MSG "WARNING: Spectre v2 mitigation leaves CPU vulnerable to RETBleed attacks, data leaks possible!\n"
2022-06-14 21:15:50 +00:00
static void __init retbleed_select_mitigation ( void )
{
2022-06-14 21:16:02 +00:00
bool mitigate_smt = false ;
2022-06-14 21:15:50 +00:00
if ( ! boot_cpu_has_bug ( X86_BUG_RETBLEED ) | | cpu_mitigations_off ( ) )
return ;
switch ( retbleed_cmd ) {
case RETBLEED_CMD_OFF :
return ;
case RETBLEED_CMD_UNRET :
2022-06-27 22:21:17 +00:00
if ( IS_ENABLED ( CONFIG_CPU_UNRET_ENTRY ) ) {
retbleed_mitigation = RETBLEED_MITIGATION_UNRET ;
} else {
pr_err ( " WARNING: kernel not compiled with CPU_UNRET_ENTRY. \n " ) ;
goto do_cmd_auto ;
}
2022-06-14 21:15:50 +00:00
break ;
2022-06-14 21:16:02 +00:00
case RETBLEED_CMD_IBPB :
2022-07-07 16:41:52 +00:00
if ( ! boot_cpu_has ( X86_FEATURE_IBPB ) ) {
pr_err ( " WARNING: CPU does not support IBPB. \n " ) ;
goto do_cmd_auto ;
} else if ( IS_ENABLED ( CONFIG_CPU_IBPB_ENTRY ) ) {
2022-06-27 22:21:17 +00:00
retbleed_mitigation = RETBLEED_MITIGATION_IBPB ;
} else {
pr_err ( " WARNING: kernel not compiled with CPU_IBPB_ENTRY. \n " ) ;
goto do_cmd_auto ;
}
2022-06-14 21:16:02 +00:00
break ;
2022-09-15 11:11:38 +00:00
case RETBLEED_CMD_STUFF :
if ( IS_ENABLED ( CONFIG_CALL_DEPTH_TRACKING ) & &
spectre_v2_enabled = = SPECTRE_V2_RETPOLINE ) {
retbleed_mitigation = RETBLEED_MITIGATION_STUFF ;
} else {
if ( IS_ENABLED ( CONFIG_CALL_DEPTH_TRACKING ) )
pr_err ( " WARNING: retbleed=stuff depends on spectre_v2=retpoline \n " ) ;
else
pr_err ( " WARNING: kernel not compiled with CALL_DEPTH_TRACKING. \n " ) ;
goto do_cmd_auto ;
}
break ;
2022-06-27 22:21:17 +00:00
do_cmd_auto :
2022-06-14 21:15:50 +00:00
case RETBLEED_CMD_AUTO :
default :
if ( boot_cpu_data . x86_vendor = = X86_VENDOR_AMD | |
2022-06-27 22:21:17 +00:00
boot_cpu_data . x86_vendor = = X86_VENDOR_HYGON ) {
if ( IS_ENABLED ( CONFIG_CPU_UNRET_ENTRY ) )
retbleed_mitigation = RETBLEED_MITIGATION_UNRET ;
2022-07-07 16:41:52 +00:00
else if ( IS_ENABLED ( CONFIG_CPU_IBPB_ENTRY ) & & boot_cpu_has ( X86_FEATURE_IBPB ) )
2022-06-27 22:21:17 +00:00
retbleed_mitigation = RETBLEED_MITIGATION_IBPB ;
}
2022-06-24 11:48:58 +00:00
/*
2022-06-14 22:07:19 +00:00
* The Intel mitigation ( IBRS or eIBRS ) was already selected in
* spectre_v2_select_mitigation ( ) . ' retbleed_mitigation ' will
* be set accordingly below .
2022-06-24 11:48:58 +00:00
*/
2022-06-14 21:15:50 +00:00
break ;
}
switch ( retbleed_mitigation ) {
case RETBLEED_MITIGATION_UNRET :
setup_force_cpu_cap ( X86_FEATURE_RETHUNK ) ;
setup_force_cpu_cap ( X86_FEATURE_UNRET ) ;
if ( boot_cpu_data . x86_vendor ! = X86_VENDOR_AMD & &
boot_cpu_data . x86_vendor ! = X86_VENDOR_HYGON )
pr_err ( RETBLEED_UNTRAIN_MSG ) ;
2022-06-14 21:16:02 +00:00
mitigate_smt = true ;
break ;
case RETBLEED_MITIGATION_IBPB :
setup_force_cpu_cap ( X86_FEATURE_ENTRY_IBPB ) ;
mitigate_smt = true ;
2022-06-14 21:15:50 +00:00
break ;
2022-09-15 11:11:38 +00:00
case RETBLEED_MITIGATION_STUFF :
setup_force_cpu_cap ( X86_FEATURE_RETHUNK ) ;
setup_force_cpu_cap ( X86_FEATURE_CALL_DEPTH ) ;
x86_set_skl_return_thunk ( ) ;
break ;
2022-06-14 21:15:50 +00:00
default :
break ;
}
2022-06-14 21:16:02 +00:00
if ( mitigate_smt & & ! boot_cpu_has ( X86_FEATURE_STIBP ) & &
( retbleed_nosmt | | cpu_mitigations_auto_nosmt ( ) ) )
cpu_smt_disable ( false ) ;
2022-06-24 11:48:58 +00:00
/*
* Let IBRS trump all on Intel without affecting the effects of the
2022-09-15 11:11:38 +00:00
* retbleed = cmdline option except for call depth based stuffing
2022-06-24 11:48:58 +00:00
*/
if ( boot_cpu_data . x86_vendor = = X86_VENDOR_INTEL ) {
switch ( spectre_v2_enabled ) {
case SPECTRE_V2_IBRS :
retbleed_mitigation = RETBLEED_MITIGATION_IBRS ;
break ;
case SPECTRE_V2_EIBRS :
case SPECTRE_V2_EIBRS_RETPOLINE :
case SPECTRE_V2_EIBRS_LFENCE :
retbleed_mitigation = RETBLEED_MITIGATION_EIBRS ;
break ;
default :
2022-09-15 11:11:38 +00:00
if ( retbleed_mitigation ! = RETBLEED_MITIGATION_STUFF )
pr_err ( RETBLEED_INTEL_MSG ) ;
2022-06-24 11:48:58 +00:00
}
}
2022-06-14 21:15:50 +00:00
pr_info ( " %s \n " , retbleed_strings [ retbleed_mitigation ] ) ;
}
2018-11-25 18:33:41 +00:00
# undef pr_fmt
# define pr_fmt(fmt) "Spectre V2 : " fmt
x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.
When STIBP is unavailable or enhanced IBRS is available, Linux
force-disables the IBPB mitigation of Spectre-BTB even when simultaneous
multithreading is disabled. While attempts to enable IBPB using
prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, ...) fail with
EPERM, the seccomp syscall (or its prctl(PR_SET_SECCOMP, ...) equivalent)
which are used e.g. by Chromium or OpenSSH succeed with no errors but the
application remains silently vulnerable to cross-process Spectre v2 attacks
(classical BTB poisoning). At the same time the SYSFS reporting
(/sys/devices/system/cpu/vulnerabilities/spectre_v2) displays that IBPB is
conditionally enabled when in fact it is unconditionally disabled.
STIBP is useful only when SMT is enabled. When SMT is disabled and STIBP is
unavailable, it makes no sense to force-disable also IBPB, because IBPB
protects against cross-process Spectre-BTB attacks regardless of the SMT
state. At the same time since missing STIBP was only observed on AMD CPUs,
AMD does not recommend using STIBP, but recommends using IBPB, so disabling
IBPB because of missing STIBP goes directly against AMD's advice:
https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf
Similarly, enhanced IBRS is designed to protect cross-core BTB poisoning
and BTB-poisoning attacks from user space against kernel (and
BTB-poisoning attacks from guest against hypervisor), it is not designed
to prevent cross-process (or cross-VM) BTB poisoning between processes (or
VMs) running on the same core. Therefore, even with enhanced IBRS it is
necessary to flush the BTB during context-switches, so there is no reason
to force disable IBPB when enhanced IBRS is available.
Enable the prctl control of IBPB even when STIBP is unavailable or enhanced
IBRS is available.
Fixes: 7cc765a67d8e ("x86/speculation: Enable prctl mode for spectre_v2_user")
Signed-off-by: Anthony Steinhauser <asteinhauser@google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
2020-05-19 13:40:42 +00:00
static enum spectre_v2_user_mitigation spectre_v2_user_stibp __ro_after_init =
SPECTRE_V2_USER_NONE ;
static enum spectre_v2_user_mitigation spectre_v2_user_ibpb __ro_after_init =
2018-11-25 18:33:45 +00:00
SPECTRE_V2_USER_NONE ;
2018-12-10 16:37:25 +00:00
# ifdef CONFIG_RETPOLINE
2018-01-27 14:45:14 +00:00
static bool spectre_v2_bad_module ;
2018-01-25 23:50:28 +00:00
bool retpoline_module_ok ( bool has_retpoline )
{
if ( spectre_v2_enabled = = SPECTRE_V2_NONE | | has_retpoline )
return true ;
2018-01-30 19:32:18 +00:00
pr_err ( " System may be vulnerable to spectre v2 \n " ) ;
2018-01-25 23:50:28 +00:00
spectre_v2_bad_module = true ;
return false ;
}
2018-01-27 14:45:14 +00:00
static inline const char * spectre_v2_module_string ( void )
{
return spectre_v2_bad_module ? " - vulnerable module loaded " : " " ;
}
# else
static inline const char * spectre_v2_module_string ( void ) { return " " ; }
2018-01-25 23:50:28 +00:00
# endif
2018-01-11 21:46:26 +00:00
2022-02-25 22:31:49 +00:00
# define SPECTRE_V2_LFENCE_MSG "WARNING: LFENCE mitigation is not recommended for this CPU, data leaks possible!\n"
2022-02-18 19:49:08 +00:00
# define SPECTRE_V2_EIBRS_EBPF_MSG "WARNING: Unprivileged eBPF is enabled with eIBRS on, data leaks possible via Spectre v2 BHB attacks!\n"
2022-02-25 22:32:28 +00:00
# define SPECTRE_V2_EIBRS_LFENCE_EBPF_SMT_MSG "WARNING: Unprivileged eBPF is enabled with eIBRS+LFENCE mitigation and SMT, data leaks possible via Spectre v2 BHB attacks!\n"
2022-07-14 23:15:35 +00:00
# define SPECTRE_V2_IBRS_PERF_MSG "WARNING: IBRS mitigation selected on Enhanced IBRS CPU, this may cause unnecessary performance loss\n"
2022-02-18 19:49:08 +00:00
# ifdef CONFIG_BPF_SYSCALL
void unpriv_ebpf_notify ( int new_state )
{
2022-02-25 22:32:28 +00:00
if ( new_state )
return ;
/* Unprivileged eBPF is enabled */
switch ( spectre_v2_enabled ) {
case SPECTRE_V2_EIBRS :
2022-02-18 19:49:08 +00:00
pr_err ( SPECTRE_V2_EIBRS_EBPF_MSG ) ;
2022-02-25 22:32:28 +00:00
break ;
case SPECTRE_V2_EIBRS_LFENCE :
if ( sched_smt_active ( ) )
pr_err ( SPECTRE_V2_EIBRS_LFENCE_EBPF_SMT_MSG ) ;
break ;
default :
break ;
}
2022-02-18 19:49:08 +00:00
}
# endif
2018-01-11 21:46:26 +00:00
static inline bool match_option ( const char * arg , int arglen , const char * opt )
{
int len = strlen ( opt ) ;
return len = = arglen & & ! strncmp ( arg , opt , len ) ;
}
2018-11-25 18:33:41 +00:00
/* The kernel command line selection for spectre v2 */
enum spectre_v2_mitigation_cmd {
SPECTRE_V2_CMD_NONE ,
SPECTRE_V2_CMD_AUTO ,
SPECTRE_V2_CMD_FORCE ,
SPECTRE_V2_CMD_RETPOLINE ,
SPECTRE_V2_CMD_RETPOLINE_GENERIC ,
2022-02-16 19:57:00 +00:00
SPECTRE_V2_CMD_RETPOLINE_LFENCE ,
2022-02-16 19:57:01 +00:00
SPECTRE_V2_CMD_EIBRS ,
SPECTRE_V2_CMD_EIBRS_RETPOLINE ,
SPECTRE_V2_CMD_EIBRS_LFENCE ,
2022-06-14 21:15:55 +00:00
SPECTRE_V2_CMD_IBRS ,
2018-11-25 18:33:41 +00:00
} ;
2018-11-25 18:33:45 +00:00
enum spectre_v2_user_cmd {
SPECTRE_V2_USER_CMD_NONE ,
SPECTRE_V2_USER_CMD_AUTO ,
SPECTRE_V2_USER_CMD_FORCE ,
2018-11-25 18:33:54 +00:00
SPECTRE_V2_USER_CMD_PRCTL ,
2018-11-25 18:33:56 +00:00
SPECTRE_V2_USER_CMD_PRCTL_IBPB ,
2018-11-25 18:33:55 +00:00
SPECTRE_V2_USER_CMD_SECCOMP ,
2018-11-25 18:33:56 +00:00
SPECTRE_V2_USER_CMD_SECCOMP_IBPB ,
2018-11-25 18:33:45 +00:00
} ;
static const char * const spectre_v2_user_strings [ ] = {
2018-12-13 23:03:54 +00:00
[ SPECTRE_V2_USER_NONE ] = " User space: Vulnerable " ,
[ SPECTRE_V2_USER_STRICT ] = " User space: Mitigation: STIBP protection " ,
[ SPECTRE_V2_USER_STRICT_PREFERRED ] = " User space: Mitigation: STIBP always-on protection " ,
[ SPECTRE_V2_USER_PRCTL ] = " User space: Mitigation: STIBP via prctl " ,
[ SPECTRE_V2_USER_SECCOMP ] = " User space: Mitigation: STIBP via seccomp and prctl " ,
2018-11-25 18:33:45 +00:00
} ;
static const struct {
const char * option ;
enum spectre_v2_user_cmd cmd ;
bool secure ;
2019-03-30 00:47:43 +00:00
} v2_user_options [ ] __initconst = {
2018-11-25 18:33:56 +00:00
{ " auto " , SPECTRE_V2_USER_CMD_AUTO , false } ,
{ " off " , SPECTRE_V2_USER_CMD_NONE , false } ,
{ " on " , SPECTRE_V2_USER_CMD_FORCE , true } ,
{ " prctl " , SPECTRE_V2_USER_CMD_PRCTL , false } ,
{ " prctl,ibpb " , SPECTRE_V2_USER_CMD_PRCTL_IBPB , false } ,
{ " seccomp " , SPECTRE_V2_USER_CMD_SECCOMP , false } ,
{ " seccomp,ibpb " , SPECTRE_V2_USER_CMD_SECCOMP_IBPB , false } ,
2018-11-25 18:33:45 +00:00
} ;
static void __init spec_v2_user_print_cond ( const char * reason , bool secure )
{
if ( boot_cpu_has_bug ( X86_BUG_SPECTRE_V2 ) ! = secure )
pr_info ( " spectre_v2_user=%s forced on command line. \n " , reason ) ;
}
2022-06-14 21:15:56 +00:00
static __ro_after_init enum spectre_v2_mitigation_cmd spectre_v2_cmd ;
2018-11-25 18:33:45 +00:00
static enum spectre_v2_user_cmd __init
2022-06-14 21:15:56 +00:00
spectre_v2_parse_user_cmdline ( void )
2018-11-25 18:33:45 +00:00
{
char arg [ 20 ] ;
int ret , i ;
2022-06-14 21:15:56 +00:00
switch ( spectre_v2_cmd ) {
2018-11-25 18:33:45 +00:00
case SPECTRE_V2_CMD_NONE :
return SPECTRE_V2_USER_CMD_NONE ;
case SPECTRE_V2_CMD_FORCE :
return SPECTRE_V2_USER_CMD_FORCE ;
default :
break ;
}
ret = cmdline_find_option ( boot_command_line , " spectre_v2_user " ,
arg , sizeof ( arg ) ) ;
if ( ret < 0 )
return SPECTRE_V2_USER_CMD_AUTO ;
for ( i = 0 ; i < ARRAY_SIZE ( v2_user_options ) ; i + + ) {
if ( match_option ( arg , ret , v2_user_options [ i ] . option ) ) {
spec_v2_user_print_cond ( v2_user_options [ i ] . option ,
v2_user_options [ i ] . secure ) ;
return v2_user_options [ i ] . cmd ;
}
}
pr_err ( " Unknown user space protection option (%s). Switching to AUTO select \n " , arg ) ;
return SPECTRE_V2_USER_CMD_AUTO ;
}
2023-02-27 06:05:40 +00:00
static inline bool spectre_v2_in_ibrs_mode ( enum spectre_v2_mitigation mode )
{
return spectre_v2_in_eibrs_mode ( mode ) | | mode = = SPECTRE_V2_IBRS ;
}
2018-11-25 18:33:45 +00:00
static void __init
2022-06-14 21:15:56 +00:00
spectre_v2_user_select_mitigation ( void )
2018-11-25 18:33:45 +00:00
{
enum spectre_v2_user_mitigation mode = SPECTRE_V2_USER_NONE ;
bool smt_possible = IS_ENABLED ( CONFIG_SMP ) ;
2018-11-25 18:33:56 +00:00
enum spectre_v2_user_cmd cmd ;
2018-11-25 18:33:45 +00:00
if ( ! boot_cpu_has ( X86_FEATURE_IBPB ) & & ! boot_cpu_has ( X86_FEATURE_STIBP ) )
return ;
if ( cpu_smt_control = = CPU_SMT_FORCE_DISABLED | |
cpu_smt_control = = CPU_SMT_NOT_SUPPORTED )
smt_possible = false ;
2022-06-14 21:15:56 +00:00
cmd = spectre_v2_parse_user_cmdline ( ) ;
2018-11-25 18:33:56 +00:00
switch ( cmd ) {
2018-11-25 18:33:45 +00:00
case SPECTRE_V2_USER_CMD_NONE :
goto set_mode ;
case SPECTRE_V2_USER_CMD_FORCE :
mode = SPECTRE_V2_USER_STRICT ;
break ;
x86: change default to spec_store_bypass_disable=prctl spectre_v2_user=prctl
Switch the kernel default of SSBD and STIBP to the ones with
CONFIG_SECCOMP=n (i.e. spec_store_bypass_disable=prctl
spectre_v2_user=prctl) even if CONFIG_SECCOMP=y.
Several motivations listed below:
- If SMT is enabled the seccomp jail can still attack the rest of the
system even with spectre_v2_user=seccomp by using MDS-HT (except on
XEON PHI where MDS can be tamed with SMT left enabled, but that's a
special case). Setting STIBP become a very expensive window dressing
after MDS-HT was discovered.
- The seccomp jail cannot attack the kernel with spectre-v2-HT
regardless (even if STIBP is not set), but with MDS-HT the seccomp
jail can attack the kernel too.
- With spec_store_bypass_disable=prctl the seccomp jail can attack the
other userland (guest or host mode) using spectre-v2-HT, but the
userland attack is already mitigated by both ASLR and pid namespaces
for host userland and through virt isolation with libkrun or
kata. (if something if somebody is worried about spectre-v2-HT it's
best to mount proc with hidepid=2,gid=proc on workstations where not
all apps may run under container runtimes, rather than slowing down
all seccomp jails, but the best is to add pid namespaces to the
seccomp jail). As opposed MDS-HT is not mitigated and the seccomp
jail can still attack all other host and guest userland if SMT is
enabled even with spec_store_bypass_disable=seccomp.
- If full security is required then MDS-HT must also be mitigated with
nosmt and then spectre_v2_user=prctl and spectre_v2_user=seccomp
would become identical.
- Setting spectre_v2_user=seccomp is overall lower priority than to
setting javascript.options.wasm false in about:config to protect
against remote wasm MDS-HT, instead of worrying about Spectre-v2-HT
and STIBP which again is already statistically well mitigated by
other means in userland and it's fully mitigated in kernel with
retpolines (unlike the wasm assist call with MDS-HT).
- SSBD is needed to prevent reading the JIT memory and the primary
user being the OpenJDK. However the primary user of SSBD wouldn't be
covered by spec_store_bypass_disable=seccomp because it doesn't use
seccomp and the primary user also explicitly declined to set
PR_SET_SPECULATION_CTRL+PR_SPEC_STORE_BYPASS despite it easily
could. In fact it would need to set it only when the sandboxing
mechanism is enabled for javaws applets, but it still declined it by
declaring security within the same user address space as an
untenable objective for their JIT, even in the sandboxing case where
performance would be a lesser concern (for the record: I kind of
disagree in not setting PR_SPEC_STORE_BYPASS in the sandbox case and
I prefer to run javaws through a wrapper that sets
PR_SPEC_STORE_BYPASS if I need). In turn it can be inferred that
even if the primary user of SSBD would use seccomp, they would
invoke it with SECCOMP_FILTER_FLAG_SPEC_ALLOW by now.
- runc/crun already set SECCOMP_FILTER_FLAG_SPEC_ALLOW by default, k8s
and podman have a default json seccomp allowlist that cannot be
slowed down, so for the #1 seccomp user this change is already a
noop.
- systemd/sshd or other apps that use seccomp, if they really need
STIBP or SSBD, they need to explicitly set the
PR_SET_SPECULATION_CTRL by now. The stibp/ssbd seccomp blind
catch-all approach was done probably initially with a wishful
thinking objective to pretend to have a peace of mind that it could
magically fix it all. That was wishful thinking before MDS-HT was
discovered, but after MDS-HT has been discovered it become just
window dressing.
- For qemu "-sandbox" seccomp jail it wouldn't make sense to set STIBP
or SSBD. SSBD doesn't help with KVM because there's no JIT (if it's
needed with TCG it should be an opt-in with
PR_SET_SPECULATION_CTRL+PR_SPEC_STORE_BYPASS and it shouldn't
slowdown KVM for nothing). For qemu+KVM STIBP would be even more
window dressing than it is for all other apps, because in the
qemu+KVM case there's not only the MDS attack to worry about with
SMT enabled. Even after disabling SMT, there's still a theoretical
spectre-v2 attack possible within the same thread context from guest
mode to host ring3 that the host kernel retpoline mitigation has no
theoretical chance to mitigate. On some kernels a
ibrs-always/ibrs-retpoline opt-in model is provided that will
enabled IBRS in the qemu host ring3 userland which fixes this
theoretical concern. Only after enabling IBRS in the host userland
it would then make sense to proceed and worry about STIBP and an
attack on the other host userland, but then again SMT would need to
be disabled for full security anyway, so that would render STIBP
again a noop.
- last but not the least: the lack of "spec_store_bypass_disable=prctl
spectre_v2_user=prctl" means the moment a guest boots and
sshd/systemd runs, the guest kernel will write to SPEC_CTRL MSR
which will make the guest vmexit forever slower, forcing KVM to
issue a very slow rdmsr instruction at every vmexit. So the end
result is that SPEC_CTRL MSR is only available in GCE. Most other
public cloud providers don't expose SPEC_CTRL, which means that not
only STIBP/SSBD isn't available, but IBPB isn't available either
(which would cause no overhead to the guest or the hypervisor
because it's write only and requires no reading during vmexit). So
the current default already net loss in security (missing IBPB)
which means most public cloud providers cannot achieve a fully
secure guest with nosmt (and nosmt is enough to fully mitigate
MDS-HT). It also means GCE and is unfairly penalized in performance
because it provides the option to enable full security in the guest
as an opt-in (i.e. nosmt and IBPB). So this change will allow all
cloud providers to expose SPEC_CTRL without incurring into any
hypervisor slowdown and at the same time it will remove the unfair
penalization of GCE performance for doing the right thing and it'll
allow to get full security with nosmt with IBPB being available (and
STIBP becoming meaningless).
Example to put things in prospective: the STIBP enabled in seccomp has
never been about protecting apps using seccomp like sshd from an
attack from a malicious userland, but to the contrary it has always
been about protecting the system from an attack from sshd, after a
successful remote network exploit against sshd. In fact initially it
wasn't obvious STIBP would work both ways (STIBP was about preventing
the task that runs with STIBP to be attacked with spectre-v2-HT, but
accidentally in the STIBP case it also prevents the attack in the
other direction). In the hypothetical case that sshd has been remotely
exploited the last concern should be STIBP being set, because it'll be
still possible to obtain info even from the kernel by using MDS if
nosmt wasn't set (and if it was set, STIBP is a noop in the first
place). As opposed kernel cannot leak anything with spectre-v2 HT
because of retpolines and the userland is mitigated by ASLR already
and ideally PID namespaces too. If something it'd be worth checking if
sshd run the seccomp thread under pid namespaces too if available in
the running kernel. SSBD also would be a noop for sshd, since sshd
uses no JIT. If sshd prefers to keep doing the STIBP window dressing
exercise, it still can even after this change of defaults by opting-in
with PR_SPEC_INDIRECT_BRANCH.
Ultimately setting SSBD and STIBP by default for all seccomp jails is
a bad sweet spot and bad default with more cons than pros that end up
reducing security in the public cloud (by giving an huge incentive to
not expose SPEC_CTRL which would be needed to get full security with
IBPB after setting nosmt in the guest) and by excessively hurting
performance to more secure apps using seccomp that end up having to
opt out with SECCOMP_FILTER_FLAG_SPEC_ALLOW.
The following is the verified result of the new default with SMT
enabled:
(gdb) print spectre_v2_user_stibp
$1 = SPECTRE_V2_USER_PRCTL
(gdb) print spectre_v2_user_ibpb
$2 = SPECTRE_V2_USER_PRCTL
(gdb) print ssb_mode
$3 = SPEC_STORE_BYPASS_PRCTL
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20201104235054.5678-1-aarcange@redhat.com
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Link: https://lore.kernel.org/lkml/AAA2EF2C-293D-4D5B-BFA6-FF655105CD84@redhat.com
Acked-by: Waiman Long <longman@redhat.com>
Link: https://lore.kernel.org/lkml/c0722838-06f7-da6b-138f-e0f26362f16a@redhat.com
2020-11-04 23:50:54 +00:00
case SPECTRE_V2_USER_CMD_AUTO :
2018-11-25 18:33:54 +00:00
case SPECTRE_V2_USER_CMD_PRCTL :
2018-11-25 18:33:56 +00:00
case SPECTRE_V2_USER_CMD_PRCTL_IBPB :
2018-11-25 18:33:54 +00:00
mode = SPECTRE_V2_USER_PRCTL ;
break ;
2018-11-25 18:33:55 +00:00
case SPECTRE_V2_USER_CMD_SECCOMP :
2018-11-25 18:33:56 +00:00
case SPECTRE_V2_USER_CMD_SECCOMP_IBPB :
2018-11-25 18:33:55 +00:00
if ( IS_ENABLED ( CONFIG_SECCOMP ) )
mode = SPECTRE_V2_USER_SECCOMP ;
else
mode = SPECTRE_V2_USER_PRCTL ;
break ;
2018-11-25 18:33:45 +00:00
}
/* Initialize Indirect Branch Prediction Barrier */
if ( boot_cpu_has ( X86_FEATURE_IBPB ) ) {
setup_force_cpu_cap ( X86_FEATURE_USE_IBPB ) ;
2018-11-25 18:33:49 +00:00
x86/speculation: Fix prctl() when spectre_v2_user={seccomp,prctl},ibpb
When spectre_v2_user={seccomp,prctl},ibpb is specified on the command
line, IBPB is force-enabled and STIPB is conditionally-enabled (or not
available).
However, since
21998a351512 ("x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.")
the spectre_v2_user_ibpb variable is set to SPECTRE_V2_USER_{PRCTL,SECCOMP}
instead of SPECTRE_V2_USER_STRICT, which is the actual behaviour.
Because the issuing of IBPB relies on the switch_mm_*_ibpb static
branches, the mitigations behave as expected.
Since
1978b3a53a74 ("x86/speculation: Allow IBPB to be conditionally enabled on CPUs with always-on STIBP")
this discrepency caused the misreporting of IB speculation via prctl().
On CPUs with STIBP always-on and spectre_v2_user=seccomp,ibpb,
prctl(PR_GET_SPECULATION_CTRL) would return PR_SPEC_PRCTL |
PR_SPEC_ENABLE instead of PR_SPEC_DISABLE since both IBPB and STIPB are
always on. It also allowed prctl(PR_SET_SPECULATION_CTRL) to set the IB
speculation mode, even though the flag is ignored.
Similarly, for CPUs without SMT, prctl(PR_GET_SPECULATION_CTRL) should
also return PR_SPEC_DISABLE since IBPB is always on and STIBP is not
available.
[ bp: Massage commit message. ]
Fixes: 21998a351512 ("x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.")
Fixes: 1978b3a53a74 ("x86/speculation: Allow IBPB to be conditionally enabled on CPUs with always-on STIBP")
Signed-off-by: Anand K Mistry <amistry@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: <stable@vger.kernel.org>
Link: https://lkml.kernel.org/r/20201110123349.1.Id0cbf996d2151f4c143c90f9028651a5b49a5908@changeid
2020-11-10 01:33:53 +00:00
spectre_v2_user_ibpb = mode ;
2018-11-25 18:33:56 +00:00
switch ( cmd ) {
case SPECTRE_V2_USER_CMD_FORCE :
case SPECTRE_V2_USER_CMD_PRCTL_IBPB :
case SPECTRE_V2_USER_CMD_SECCOMP_IBPB :
2018-11-25 18:33:49 +00:00
static_branch_enable ( & switch_mm_always_ibpb ) ;
x86/speculation: Fix prctl() when spectre_v2_user={seccomp,prctl},ibpb
When spectre_v2_user={seccomp,prctl},ibpb is specified on the command
line, IBPB is force-enabled and STIPB is conditionally-enabled (or not
available).
However, since
21998a351512 ("x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.")
the spectre_v2_user_ibpb variable is set to SPECTRE_V2_USER_{PRCTL,SECCOMP}
instead of SPECTRE_V2_USER_STRICT, which is the actual behaviour.
Because the issuing of IBPB relies on the switch_mm_*_ibpb static
branches, the mitigations behave as expected.
Since
1978b3a53a74 ("x86/speculation: Allow IBPB to be conditionally enabled on CPUs with always-on STIBP")
this discrepency caused the misreporting of IB speculation via prctl().
On CPUs with STIBP always-on and spectre_v2_user=seccomp,ibpb,
prctl(PR_GET_SPECULATION_CTRL) would return PR_SPEC_PRCTL |
PR_SPEC_ENABLE instead of PR_SPEC_DISABLE since both IBPB and STIPB are
always on. It also allowed prctl(PR_SET_SPECULATION_CTRL) to set the IB
speculation mode, even though the flag is ignored.
Similarly, for CPUs without SMT, prctl(PR_GET_SPECULATION_CTRL) should
also return PR_SPEC_DISABLE since IBPB is always on and STIBP is not
available.
[ bp: Massage commit message. ]
Fixes: 21998a351512 ("x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.")
Fixes: 1978b3a53a74 ("x86/speculation: Allow IBPB to be conditionally enabled on CPUs with always-on STIBP")
Signed-off-by: Anand K Mistry <amistry@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: <stable@vger.kernel.org>
Link: https://lkml.kernel.org/r/20201110123349.1.Id0cbf996d2151f4c143c90f9028651a5b49a5908@changeid
2020-11-10 01:33:53 +00:00
spectre_v2_user_ibpb = SPECTRE_V2_USER_STRICT ;
2018-11-25 18:33:49 +00:00
break ;
2018-11-25 18:33:56 +00:00
case SPECTRE_V2_USER_CMD_PRCTL :
case SPECTRE_V2_USER_CMD_AUTO :
case SPECTRE_V2_USER_CMD_SECCOMP :
2018-11-25 18:33:54 +00:00
static_branch_enable ( & switch_mm_cond_ibpb ) ;
break ;
2018-11-25 18:33:49 +00:00
default :
break ;
}
pr_info ( " mitigation: Enabling %s Indirect Branch Prediction Barrier \n " ,
2018-11-25 18:33:56 +00:00
static_key_enabled ( & switch_mm_always_ibpb ) ?
" always-on " : " conditional " ) ;
2018-11-25 18:33:45 +00:00
}
x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.
When STIBP is unavailable or enhanced IBRS is available, Linux
force-disables the IBPB mitigation of Spectre-BTB even when simultaneous
multithreading is disabled. While attempts to enable IBPB using
prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, ...) fail with
EPERM, the seccomp syscall (or its prctl(PR_SET_SECCOMP, ...) equivalent)
which are used e.g. by Chromium or OpenSSH succeed with no errors but the
application remains silently vulnerable to cross-process Spectre v2 attacks
(classical BTB poisoning). At the same time the SYSFS reporting
(/sys/devices/system/cpu/vulnerabilities/spectre_v2) displays that IBPB is
conditionally enabled when in fact it is unconditionally disabled.
STIBP is useful only when SMT is enabled. When SMT is disabled and STIBP is
unavailable, it makes no sense to force-disable also IBPB, because IBPB
protects against cross-process Spectre-BTB attacks regardless of the SMT
state. At the same time since missing STIBP was only observed on AMD CPUs,
AMD does not recommend using STIBP, but recommends using IBPB, so disabling
IBPB because of missing STIBP goes directly against AMD's advice:
https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf
Similarly, enhanced IBRS is designed to protect cross-core BTB poisoning
and BTB-poisoning attacks from user space against kernel (and
BTB-poisoning attacks from guest against hypervisor), it is not designed
to prevent cross-process (or cross-VM) BTB poisoning between processes (or
VMs) running on the same core. Therefore, even with enhanced IBRS it is
necessary to flush the BTB during context-switches, so there is no reason
to force disable IBPB when enhanced IBRS is available.
Enable the prctl control of IBPB even when STIBP is unavailable or enhanced
IBRS is available.
Fixes: 7cc765a67d8e ("x86/speculation: Enable prctl mode for spectre_v2_user")
Signed-off-by: Anthony Steinhauser <asteinhauser@google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
2020-05-19 13:40:42 +00:00
/*
2023-02-27 06:05:40 +00:00
* If no STIBP , enhanced IBRS is enabled , or SMT impossible , STIBP
* is not required .
*
* Enhanced IBRS also protects against cross - thread branch target
* injection in user - mode as the IBRS bit remains always set which
* implicitly enables cross - thread protections . However , in legacy IBRS
* mode , the IBRS bit is set only on kernel entry and cleared on return
* to userspace . This disables the implicit cross - thread protection ,
* so allow for STIBP to be selected in that case .
x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.
When STIBP is unavailable or enhanced IBRS is available, Linux
force-disables the IBPB mitigation of Spectre-BTB even when simultaneous
multithreading is disabled. While attempts to enable IBPB using
prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, ...) fail with
EPERM, the seccomp syscall (or its prctl(PR_SET_SECCOMP, ...) equivalent)
which are used e.g. by Chromium or OpenSSH succeed with no errors but the
application remains silently vulnerable to cross-process Spectre v2 attacks
(classical BTB poisoning). At the same time the SYSFS reporting
(/sys/devices/system/cpu/vulnerabilities/spectre_v2) displays that IBPB is
conditionally enabled when in fact it is unconditionally disabled.
STIBP is useful only when SMT is enabled. When SMT is disabled and STIBP is
unavailable, it makes no sense to force-disable also IBPB, because IBPB
protects against cross-process Spectre-BTB attacks regardless of the SMT
state. At the same time since missing STIBP was only observed on AMD CPUs,
AMD does not recommend using STIBP, but recommends using IBPB, so disabling
IBPB because of missing STIBP goes directly against AMD's advice:
https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf
Similarly, enhanced IBRS is designed to protect cross-core BTB poisoning
and BTB-poisoning attacks from user space against kernel (and
BTB-poisoning attacks from guest against hypervisor), it is not designed
to prevent cross-process (or cross-VM) BTB poisoning between processes (or
VMs) running on the same core. Therefore, even with enhanced IBRS it is
necessary to flush the BTB during context-switches, so there is no reason
to force disable IBPB when enhanced IBRS is available.
Enable the prctl control of IBPB even when STIBP is unavailable or enhanced
IBRS is available.
Fixes: 7cc765a67d8e ("x86/speculation: Enable prctl mode for spectre_v2_user")
Signed-off-by: Anthony Steinhauser <asteinhauser@google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
2020-05-19 13:40:42 +00:00
*/
2020-06-15 06:51:25 +00:00
if ( ! boot_cpu_has ( X86_FEATURE_STIBP ) | |
! smt_possible | |
2023-02-27 06:05:40 +00:00
spectre_v2_in_eibrs_mode ( spectre_v2_enabled ) )
2018-11-25 18:33:45 +00:00
return ;
2018-11-25 18:33:54 +00:00
/*
x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.
When STIBP is unavailable or enhanced IBRS is available, Linux
force-disables the IBPB mitigation of Spectre-BTB even when simultaneous
multithreading is disabled. While attempts to enable IBPB using
prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, ...) fail with
EPERM, the seccomp syscall (or its prctl(PR_SET_SECCOMP, ...) equivalent)
which are used e.g. by Chromium or OpenSSH succeed with no errors but the
application remains silently vulnerable to cross-process Spectre v2 attacks
(classical BTB poisoning). At the same time the SYSFS reporting
(/sys/devices/system/cpu/vulnerabilities/spectre_v2) displays that IBPB is
conditionally enabled when in fact it is unconditionally disabled.
STIBP is useful only when SMT is enabled. When SMT is disabled and STIBP is
unavailable, it makes no sense to force-disable also IBPB, because IBPB
protects against cross-process Spectre-BTB attacks regardless of the SMT
state. At the same time since missing STIBP was only observed on AMD CPUs,
AMD does not recommend using STIBP, but recommends using IBPB, so disabling
IBPB because of missing STIBP goes directly against AMD's advice:
https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf
Similarly, enhanced IBRS is designed to protect cross-core BTB poisoning
and BTB-poisoning attacks from user space against kernel (and
BTB-poisoning attacks from guest against hypervisor), it is not designed
to prevent cross-process (or cross-VM) BTB poisoning between processes (or
VMs) running on the same core. Therefore, even with enhanced IBRS it is
necessary to flush the BTB during context-switches, so there is no reason
to force disable IBPB when enhanced IBRS is available.
Enable the prctl control of IBPB even when STIBP is unavailable or enhanced
IBRS is available.
Fixes: 7cc765a67d8e ("x86/speculation: Enable prctl mode for spectre_v2_user")
Signed-off-by: Anthony Steinhauser <asteinhauser@google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
2020-05-19 13:40:42 +00:00
* At this point , an STIBP mode other than " off " has been set .
* If STIBP support is not being forced , check if STIBP always - on
* is preferred .
2018-11-25 18:33:54 +00:00
*/
x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.
When STIBP is unavailable or enhanced IBRS is available, Linux
force-disables the IBPB mitigation of Spectre-BTB even when simultaneous
multithreading is disabled. While attempts to enable IBPB using
prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, ...) fail with
EPERM, the seccomp syscall (or its prctl(PR_SET_SECCOMP, ...) equivalent)
which are used e.g. by Chromium or OpenSSH succeed with no errors but the
application remains silently vulnerable to cross-process Spectre v2 attacks
(classical BTB poisoning). At the same time the SYSFS reporting
(/sys/devices/system/cpu/vulnerabilities/spectre_v2) displays that IBPB is
conditionally enabled when in fact it is unconditionally disabled.
STIBP is useful only when SMT is enabled. When SMT is disabled and STIBP is
unavailable, it makes no sense to force-disable also IBPB, because IBPB
protects against cross-process Spectre-BTB attacks regardless of the SMT
state. At the same time since missing STIBP was only observed on AMD CPUs,
AMD does not recommend using STIBP, but recommends using IBPB, so disabling
IBPB because of missing STIBP goes directly against AMD's advice:
https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf
Similarly, enhanced IBRS is designed to protect cross-core BTB poisoning
and BTB-poisoning attacks from user space against kernel (and
BTB-poisoning attacks from guest against hypervisor), it is not designed
to prevent cross-process (or cross-VM) BTB poisoning between processes (or
VMs) running on the same core. Therefore, even with enhanced IBRS it is
necessary to flush the BTB during context-switches, so there is no reason
to force disable IBPB when enhanced IBRS is available.
Enable the prctl control of IBPB even when STIBP is unavailable or enhanced
IBRS is available.
Fixes: 7cc765a67d8e ("x86/speculation: Enable prctl mode for spectre_v2_user")
Signed-off-by: Anthony Steinhauser <asteinhauser@google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
2020-05-19 13:40:42 +00:00
if ( mode ! = SPECTRE_V2_USER_STRICT & &
boot_cpu_has ( X86_FEATURE_AMD_STIBP_ALWAYS_ON ) )
mode = SPECTRE_V2_USER_STRICT_PREFERRED ;
x86/bugs: Enable STIBP for IBPB mitigated RETBleed
AMD's "Technical Guidance for Mitigating Branch Type Confusion,
Rev. 1.0 2022-07-12" whitepaper, under section 6.1.2 "IBPB On
Privileged Mode Entry / SMT Safety" says:
Similar to the Jmp2Ret mitigation, if the code on the sibling thread
cannot be trusted, software should set STIBP to 1 or disable SMT to
ensure SMT safety when using this mitigation.
So, like already being done for retbleed=unret, and now also for
retbleed=ibpb, force STIBP on machines that have it, and report its SMT
vulnerability status accordingly.
[ bp: Remove the "we" and remove "[AMD]" applicability parameter which
doesn't work here. ]
Fixes: 3ebc17006888 ("x86/bugs: Add retbleed=ibpb")
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: stable@vger.kernel.org # 5.10, 5.15, 5.19
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
Link: https://lore.kernel.org/r/20220804192201.439596-1-kim.phillips@amd.com
2022-08-08 14:32:33 +00:00
if ( retbleed_mitigation = = RETBLEED_MITIGATION_UNRET | |
retbleed_mitigation = = RETBLEED_MITIGATION_IBPB ) {
2022-06-14 21:15:51 +00:00
if ( mode ! = SPECTRE_V2_USER_STRICT & &
mode ! = SPECTRE_V2_USER_STRICT_PREFERRED )
2022-07-08 21:21:28 +00:00
pr_info ( " Selecting STIBP always-on mode to complement retbleed mitigation \n " ) ;
2022-06-14 21:15:51 +00:00
mode = SPECTRE_V2_USER_STRICT_PREFERRED ;
}
x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.
When STIBP is unavailable or enhanced IBRS is available, Linux
force-disables the IBPB mitigation of Spectre-BTB even when simultaneous
multithreading is disabled. While attempts to enable IBPB using
prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, ...) fail with
EPERM, the seccomp syscall (or its prctl(PR_SET_SECCOMP, ...) equivalent)
which are used e.g. by Chromium or OpenSSH succeed with no errors but the
application remains silently vulnerable to cross-process Spectre v2 attacks
(classical BTB poisoning). At the same time the SYSFS reporting
(/sys/devices/system/cpu/vulnerabilities/spectre_v2) displays that IBPB is
conditionally enabled when in fact it is unconditionally disabled.
STIBP is useful only when SMT is enabled. When SMT is disabled and STIBP is
unavailable, it makes no sense to force-disable also IBPB, because IBPB
protects against cross-process Spectre-BTB attacks regardless of the SMT
state. At the same time since missing STIBP was only observed on AMD CPUs,
AMD does not recommend using STIBP, but recommends using IBPB, so disabling
IBPB because of missing STIBP goes directly against AMD's advice:
https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf
Similarly, enhanced IBRS is designed to protect cross-core BTB poisoning
and BTB-poisoning attacks from user space against kernel (and
BTB-poisoning attacks from guest against hypervisor), it is not designed
to prevent cross-process (or cross-VM) BTB poisoning between processes (or
VMs) running on the same core. Therefore, even with enhanced IBRS it is
necessary to flush the BTB during context-switches, so there is no reason
to force disable IBPB when enhanced IBRS is available.
Enable the prctl control of IBPB even when STIBP is unavailable or enhanced
IBRS is available.
Fixes: 7cc765a67d8e ("x86/speculation: Enable prctl mode for spectre_v2_user")
Signed-off-by: Anthony Steinhauser <asteinhauser@google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
2020-05-19 13:40:42 +00:00
spectre_v2_user_stibp = mode ;
2018-11-25 18:33:45 +00:00
set_mode :
x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.
When STIBP is unavailable or enhanced IBRS is available, Linux
force-disables the IBPB mitigation of Spectre-BTB even when simultaneous
multithreading is disabled. While attempts to enable IBPB using
prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, ...) fail with
EPERM, the seccomp syscall (or its prctl(PR_SET_SECCOMP, ...) equivalent)
which are used e.g. by Chromium or OpenSSH succeed with no errors but the
application remains silently vulnerable to cross-process Spectre v2 attacks
(classical BTB poisoning). At the same time the SYSFS reporting
(/sys/devices/system/cpu/vulnerabilities/spectre_v2) displays that IBPB is
conditionally enabled when in fact it is unconditionally disabled.
STIBP is useful only when SMT is enabled. When SMT is disabled and STIBP is
unavailable, it makes no sense to force-disable also IBPB, because IBPB
protects against cross-process Spectre-BTB attacks regardless of the SMT
state. At the same time since missing STIBP was only observed on AMD CPUs,
AMD does not recommend using STIBP, but recommends using IBPB, so disabling
IBPB because of missing STIBP goes directly against AMD's advice:
https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf
Similarly, enhanced IBRS is designed to protect cross-core BTB poisoning
and BTB-poisoning attacks from user space against kernel (and
BTB-poisoning attacks from guest against hypervisor), it is not designed
to prevent cross-process (or cross-VM) BTB poisoning between processes (or
VMs) running on the same core. Therefore, even with enhanced IBRS it is
necessary to flush the BTB during context-switches, so there is no reason
to force disable IBPB when enhanced IBRS is available.
Enable the prctl control of IBPB even when STIBP is unavailable or enhanced
IBRS is available.
Fixes: 7cc765a67d8e ("x86/speculation: Enable prctl mode for spectre_v2_user")
Signed-off-by: Anthony Steinhauser <asteinhauser@google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
2020-05-19 13:40:42 +00:00
pr_info ( " %s \n " , spectre_v2_user_strings [ mode ] ) ;
2018-11-25 18:33:45 +00:00
}
2018-11-25 18:33:42 +00:00
static const char * const spectre_v2_strings [ ] = {
2018-11-25 18:33:41 +00:00
[ SPECTRE_V2_NONE ] = " Vulnerable " ,
2022-02-16 19:57:00 +00:00
[ SPECTRE_V2_RETPOLINE ] = " Mitigation: Retpolines " ,
[ SPECTRE_V2_LFENCE ] = " Mitigation: LFENCE " ,
2023-01-24 16:33:18 +00:00
[ SPECTRE_V2_EIBRS ] = " Mitigation: Enhanced / Automatic IBRS " ,
[ SPECTRE_V2_EIBRS_LFENCE ] = " Mitigation: Enhanced / Automatic IBRS + LFENCE " ,
[ SPECTRE_V2_EIBRS_RETPOLINE ] = " Mitigation: Enhanced / Automatic IBRS + Retpolines " ,
2022-06-14 21:15:55 +00:00
[ SPECTRE_V2_IBRS ] = " Mitigation: IBRS " ,
2018-11-25 18:33:41 +00:00
} ;
2018-02-01 11:27:21 +00:00
static const struct {
const char * option ;
enum spectre_v2_mitigation_cmd cmd ;
bool secure ;
2019-03-30 00:47:43 +00:00
} mitigation_options [ ] __initconst = {
2018-11-25 18:33:41 +00:00
{ " off " , SPECTRE_V2_CMD_NONE , false } ,
{ " on " , SPECTRE_V2_CMD_FORCE , true } ,
{ " retpoline " , SPECTRE_V2_CMD_RETPOLINE , false } ,
2022-02-16 19:57:00 +00:00
{ " retpoline,amd " , SPECTRE_V2_CMD_RETPOLINE_LFENCE , false } ,
{ " retpoline,lfence " , SPECTRE_V2_CMD_RETPOLINE_LFENCE , false } ,
2018-11-25 18:33:41 +00:00
{ " retpoline,generic " , SPECTRE_V2_CMD_RETPOLINE_GENERIC , false } ,
2022-02-16 19:57:01 +00:00
{ " eibrs " , SPECTRE_V2_CMD_EIBRS , false } ,
{ " eibrs,lfence " , SPECTRE_V2_CMD_EIBRS_LFENCE , false } ,
{ " eibrs,retpoline " , SPECTRE_V2_CMD_EIBRS_RETPOLINE , false } ,
2018-11-25 18:33:41 +00:00
{ " auto " , SPECTRE_V2_CMD_AUTO , false } ,
2022-06-14 21:15:55 +00:00
{ " ibrs " , SPECTRE_V2_CMD_IBRS , false } ,
2018-02-01 11:27:21 +00:00
} ;
2018-11-25 18:33:44 +00:00
static void __init spec_v2_print_cond ( const char * reason , bool secure )
2018-11-25 18:33:41 +00:00
{
2018-11-25 18:33:44 +00:00
if ( boot_cpu_has_bug ( X86_BUG_SPECTRE_V2 ) ! = secure )
2018-11-25 18:33:41 +00:00
pr_info ( " %s selected on command line. \n " , reason ) ;
}
2018-01-11 21:46:26 +00:00
static enum spectre_v2_mitigation_cmd __init spectre_v2_parse_cmdline ( void )
{
2018-11-25 18:33:41 +00:00
enum spectre_v2_mitigation_cmd cmd = SPECTRE_V2_CMD_AUTO ;
2018-01-11 21:46:26 +00:00
char arg [ 20 ] ;
2018-02-01 11:27:21 +00:00
int ret , i ;
2019-04-12 20:39:29 +00:00
if ( cmdline_find_option_bool ( boot_command_line , " nospectre_v2 " ) | |
cpu_mitigations_off ( ) )
2018-02-01 11:27:21 +00:00
return SPECTRE_V2_CMD_NONE ;
2018-11-25 18:33:30 +00:00
ret = cmdline_find_option ( boot_command_line , " spectre_v2 " , arg , sizeof ( arg ) ) ;
if ( ret < 0 )
return SPECTRE_V2_CMD_AUTO ;
for ( i = 0 ; i < ARRAY_SIZE ( mitigation_options ) ; i + + ) {
if ( ! match_option ( arg , ret , mitigation_options [ i ] . option ) )
continue ;
cmd = mitigation_options [ i ] . cmd ;
break ;
}
if ( i > = ARRAY_SIZE ( mitigation_options ) ) {
pr_err ( " unknown option (%s). Switching to AUTO select \n " , arg ) ;
return SPECTRE_V2_CMD_AUTO ;
2018-01-11 21:46:26 +00:00
}
2018-02-01 11:27:21 +00:00
if ( ( cmd = = SPECTRE_V2_CMD_RETPOLINE | |
2022-02-16 19:57:00 +00:00
cmd = = SPECTRE_V2_CMD_RETPOLINE_LFENCE | |
2022-02-16 19:57:01 +00:00
cmd = = SPECTRE_V2_CMD_RETPOLINE_GENERIC | |
cmd = = SPECTRE_V2_CMD_EIBRS_LFENCE | |
cmd = = SPECTRE_V2_CMD_EIBRS_RETPOLINE ) & &
2018-02-01 11:27:21 +00:00
! IS_ENABLED ( CONFIG_RETPOLINE ) ) {
2022-02-16 19:57:01 +00:00
pr_err ( " %s selected but not compiled in. Switching to AUTO select \n " ,
mitigation_options [ i ] . option ) ;
return SPECTRE_V2_CMD_AUTO ;
}
if ( ( cmd = = SPECTRE_V2_CMD_EIBRS | |
cmd = = SPECTRE_V2_CMD_EIBRS_LFENCE | |
cmd = = SPECTRE_V2_CMD_EIBRS_RETPOLINE ) & &
! boot_cpu_has ( X86_FEATURE_IBRS_ENHANCED ) ) {
2023-01-24 16:33:18 +00:00
pr_err ( " %s selected but CPU doesn't have Enhanced or Automatic IBRS. Switching to AUTO select \n " ,
2022-02-16 19:57:01 +00:00
mitigation_options [ i ] . option ) ;
2018-01-11 21:46:26 +00:00
return SPECTRE_V2_CMD_AUTO ;
2018-02-01 11:27:21 +00:00
}
2022-02-16 19:57:01 +00:00
if ( ( cmd = = SPECTRE_V2_CMD_RETPOLINE_LFENCE | |
cmd = = SPECTRE_V2_CMD_EIBRS_LFENCE ) & &
2022-02-16 19:57:00 +00:00
! boot_cpu_has ( X86_FEATURE_LFENCE_RDTSC ) ) {
2022-02-16 19:57:01 +00:00
pr_err ( " %s selected, but CPU doesn't have a serializing LFENCE. Switching to AUTO select \n " ,
mitigation_options [ i ] . option ) ;
2022-02-16 19:57:00 +00:00
return SPECTRE_V2_CMD_AUTO ;
}
2022-06-27 22:21:17 +00:00
if ( cmd = = SPECTRE_V2_CMD_IBRS & & ! IS_ENABLED ( CONFIG_CPU_IBRS_ENTRY ) ) {
pr_err ( " %s selected but not compiled in. Switching to AUTO select \n " ,
mitigation_options [ i ] . option ) ;
return SPECTRE_V2_CMD_AUTO ;
}
2022-06-14 21:15:55 +00:00
if ( cmd = = SPECTRE_V2_CMD_IBRS & & boot_cpu_data . x86_vendor ! = X86_VENDOR_INTEL ) {
pr_err ( " %s selected but not Intel CPU. Switching to AUTO select \n " ,
mitigation_options [ i ] . option ) ;
return SPECTRE_V2_CMD_AUTO ;
}
if ( cmd = = SPECTRE_V2_CMD_IBRS & & ! boot_cpu_has ( X86_FEATURE_IBRS ) ) {
pr_err ( " %s selected but CPU doesn't have IBRS. Switching to AUTO select \n " ,
mitigation_options [ i ] . option ) ;
return SPECTRE_V2_CMD_AUTO ;
}
2022-11-04 07:27:01 +00:00
if ( cmd = = SPECTRE_V2_CMD_IBRS & & cpu_feature_enabled ( X86_FEATURE_XENPV ) ) {
2022-06-14 21:15:55 +00:00
pr_err ( " %s selected but running as XenPV guest. Switching to AUTO select \n " ,
mitigation_options [ i ] . option ) ;
return SPECTRE_V2_CMD_AUTO ;
}
2018-11-25 18:33:44 +00:00
spec_v2_print_cond ( mitigation_options [ i ] . option ,
mitigation_options [ i ] . secure ) ;
2018-02-01 11:27:21 +00:00
return cmd ;
2018-01-11 21:46:26 +00:00
}
2022-02-16 19:57:01 +00:00
static enum spectre_v2_mitigation __init spectre_v2_select_retpoline ( void )
{
if ( ! IS_ENABLED ( CONFIG_RETPOLINE ) ) {
pr_err ( " Kernel not compiled with retpoline; no mitigation available! " ) ;
return SPECTRE_V2_NONE ;
}
return SPECTRE_V2_RETPOLINE ;
}
2022-07-08 20:36:09 +00:00
/* Disable in-kernel use of non-RSB RET predictors */
static void __init spec_ctrl_disable_kernel_rrsba ( void )
{
u64 ia32_cap ;
if ( ! boot_cpu_has ( X86_FEATURE_RRSBA_CTRL ) )
return ;
ia32_cap = x86_read_arch_cap_msr ( ) ;
if ( ia32_cap & ARCH_CAP_RRSBA ) {
x86_spec_ctrl_base | = SPEC_CTRL_RRSBA_DIS_S ;
2022-11-30 15:25:51 +00:00
update_spec_ctrl ( x86_spec_ctrl_base ) ;
2022-07-08 20:36:09 +00:00
}
}
x86/speculation: Add RSB VM Exit protections
tl;dr: The Enhanced IBRS mitigation for Spectre v2 does not work as
documented for RET instructions after VM exits. Mitigate it with a new
one-entry RSB stuffing mechanism and a new LFENCE.
== Background ==
Indirect Branch Restricted Speculation (IBRS) was designed to help
mitigate Branch Target Injection and Speculative Store Bypass, i.e.
Spectre, attacks. IBRS prevents software run in less privileged modes
from affecting branch prediction in more privileged modes. IBRS requires
the MSR to be written on every privilege level change.
To overcome some of the performance issues of IBRS, Enhanced IBRS was
introduced. eIBRS is an "always on" IBRS, in other words, just turn
it on once instead of writing the MSR on every privilege level change.
When eIBRS is enabled, more privileged modes should be protected from
less privileged modes, including protecting VMMs from guests.
== Problem ==
Here's a simplification of how guests are run on Linux' KVM:
void run_kvm_guest(void)
{
// Prepare to run guest
VMRESUME();
// Clean up after guest runs
}
The execution flow for that would look something like this to the
processor:
1. Host-side: call run_kvm_guest()
2. Host-side: VMRESUME
3. Guest runs, does "CALL guest_function"
4. VM exit, host runs again
5. Host might make some "cleanup" function calls
6. Host-side: RET from run_kvm_guest()
Now, when back on the host, there are a couple of possible scenarios of
post-guest activity the host needs to do before executing host code:
* on pre-eIBRS hardware (legacy IBRS, or nothing at all), the RSB is not
touched and Linux has to do a 32-entry stuffing.
* on eIBRS hardware, VM exit with IBRS enabled, or restoring the host
IBRS=1 shortly after VM exit, has a documented side effect of flushing
the RSB except in this PBRSB situation where the software needs to stuff
the last RSB entry "by hand".
IOW, with eIBRS supported, host RET instructions should no longer be
influenced by guest behavior after the host retires a single CALL
instruction.
However, if the RET instructions are "unbalanced" with CALLs after a VM
exit as is the RET in #6, it might speculatively use the address for the
instruction after the CALL in #3 as an RSB prediction. This is a problem
since the (untrusted) guest controls this address.
Balanced CALL/RET instruction pairs such as in step #5 are not affected.
== Solution ==
The PBRSB issue affects a wide variety of Intel processors which
support eIBRS. But not all of them need mitigation. Today,
X86_FEATURE_RSB_VMEXIT triggers an RSB filling sequence that mitigates
PBRSB. Systems setting RSB_VMEXIT need no further mitigation - i.e.,
eIBRS systems which enable legacy IBRS explicitly.
However, such systems (X86_FEATURE_IBRS_ENHANCED) do not set RSB_VMEXIT
and most of them need a new mitigation.
Therefore, introduce a new feature flag X86_FEATURE_RSB_VMEXIT_LITE
which triggers a lighter-weight PBRSB mitigation versus RSB_VMEXIT.
The lighter-weight mitigation performs a CALL instruction which is
immediately followed by a speculative execution barrier (INT3). This
steers speculative execution to the barrier -- just like a retpoline
-- which ensures that speculation can never reach an unbalanced RET.
Then, ensure this CALL is retired before continuing execution with an
LFENCE.
In other words, the window of exposure is opened at VM exit where RET
behavior is troublesome. While the window is open, force RSB predictions
sampling for RET targets to a dead end at the INT3. Close the window
with the LFENCE.
There is a subset of eIBRS systems which are not vulnerable to PBRSB.
Add these systems to the cpu_vuln_whitelist[] as NO_EIBRS_PBRSB.
Future systems that aren't vulnerable will set ARCH_CAP_PBRSB_NO.
[ bp: Massage, incorporate review comments from Andy Cooper. ]
Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Co-developed-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
2022-08-02 22:47:01 +00:00
static void __init spectre_v2_determine_rsb_fill_type_at_vmexit ( enum spectre_v2_mitigation mode )
{
/*
* Similar to context switches , there are two types of RSB attacks
* after VM exit :
*
* 1 ) RSB underflow
*
* 2 ) Poisoned RSB entry
*
* When retpoline is enabled , both are mitigated by filling / clearing
* the RSB .
*
* When IBRS is enabled , while # 1 would be mitigated by the IBRS branch
* prediction isolation protections , RSB still needs to be cleared
* because of # 2. Note that SMEP provides no protection here , unlike
* user - space - poisoned RSB entries .
*
* eIBRS should protect against RSB poisoning , but if the EIBRS_PBRSB
* bug is present then a LITE version of RSB protection is required ,
* just a single call needs to retire before a RET is executed .
*/
switch ( mode ) {
case SPECTRE_V2_NONE :
return ;
case SPECTRE_V2_EIBRS_LFENCE :
case SPECTRE_V2_EIBRS :
if ( boot_cpu_has_bug ( X86_BUG_EIBRS_PBRSB ) ) {
setup_force_cpu_cap ( X86_FEATURE_RSB_VMEXIT_LITE ) ;
pr_info ( " Spectre v2 / PBRSB-eIBRS: Retire a single CALL on VMEXIT \n " ) ;
}
return ;
case SPECTRE_V2_EIBRS_RETPOLINE :
case SPECTRE_V2_RETPOLINE :
case SPECTRE_V2_LFENCE :
case SPECTRE_V2_IBRS :
setup_force_cpu_cap ( X86_FEATURE_RSB_VMEXIT ) ;
pr_info ( " Spectre v2 / SpectreRSB : Filling RSB on VMEXIT \n " ) ;
return ;
}
pr_warn_once ( " Unknown Spectre v2 mode, disabling RSB mitigation at VM exit " ) ;
dump_stack ( ) ;
}
2018-01-11 21:46:26 +00:00
static void __init spectre_v2_select_mitigation ( void )
{
enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline ( ) ;
enum spectre_v2_mitigation mode = SPECTRE_V2_NONE ;
/*
* If the CPU is not affected and the command line mode is NONE or AUTO
* then nothing to do .
*/
if ( ! boot_cpu_has_bug ( X86_BUG_SPECTRE_V2 ) & &
( cmd = = SPECTRE_V2_CMD_NONE | | cmd = = SPECTRE_V2_CMD_AUTO ) )
return ;
switch ( cmd ) {
case SPECTRE_V2_CMD_NONE :
return ;
case SPECTRE_V2_CMD_FORCE :
case SPECTRE_V2_CMD_AUTO :
2018-08-01 18:42:25 +00:00
if ( boot_cpu_has ( X86_FEATURE_IBRS_ENHANCED ) ) {
2022-02-16 19:57:01 +00:00
mode = SPECTRE_V2_EIBRS ;
break ;
2018-08-01 18:42:25 +00:00
}
2022-02-16 19:57:01 +00:00
2022-06-27 22:21:17 +00:00
if ( IS_ENABLED ( CONFIG_CPU_IBRS_ENTRY ) & &
boot_cpu_has_bug ( X86_BUG_RETBLEED ) & &
2022-06-14 21:15:55 +00:00
retbleed_cmd ! = RETBLEED_CMD_OFF & &
2022-09-15 11:11:38 +00:00
retbleed_cmd ! = RETBLEED_CMD_STUFF & &
2022-06-14 21:15:55 +00:00
boot_cpu_has ( X86_FEATURE_IBRS ) & &
boot_cpu_data . x86_vendor = = X86_VENDOR_INTEL ) {
mode = SPECTRE_V2_IBRS ;
break ;
}
2022-02-16 19:57:01 +00:00
mode = spectre_v2_select_retpoline ( ) ;
2018-01-30 06:13:50 +00:00
break ;
2022-02-16 19:57:01 +00:00
2022-02-16 19:57:00 +00:00
case SPECTRE_V2_CMD_RETPOLINE_LFENCE :
2022-02-25 22:31:49 +00:00
pr_err ( SPECTRE_V2_LFENCE_MSG ) ;
2022-02-16 19:57:01 +00:00
mode = SPECTRE_V2_LFENCE ;
2018-01-11 21:46:26 +00:00
break ;
2022-02-16 19:57:01 +00:00
2018-01-11 21:46:26 +00:00
case SPECTRE_V2_CMD_RETPOLINE_GENERIC :
2022-02-16 19:57:01 +00:00
mode = SPECTRE_V2_RETPOLINE ;
2018-01-11 21:46:26 +00:00
break ;
2022-02-16 19:57:01 +00:00
2018-01-11 21:46:26 +00:00
case SPECTRE_V2_CMD_RETPOLINE :
2022-02-16 19:57:01 +00:00
mode = spectre_v2_select_retpoline ( ) ;
break ;
2022-06-14 21:15:55 +00:00
case SPECTRE_V2_CMD_IBRS :
mode = SPECTRE_V2_IBRS ;
break ;
2022-02-16 19:57:01 +00:00
case SPECTRE_V2_CMD_EIBRS :
mode = SPECTRE_V2_EIBRS ;
break ;
case SPECTRE_V2_CMD_EIBRS_LFENCE :
mode = SPECTRE_V2_EIBRS_LFENCE ;
break ;
case SPECTRE_V2_CMD_EIBRS_RETPOLINE :
mode = SPECTRE_V2_EIBRS_RETPOLINE ;
2018-01-11 21:46:26 +00:00
break ;
}
2022-02-18 19:49:08 +00:00
if ( mode = = SPECTRE_V2_EIBRS & & unprivileged_ebpf_enabled ( ) )
pr_err ( SPECTRE_V2_EIBRS_EBPF_MSG ) ;
2022-06-14 21:15:55 +00:00
if ( spectre_v2_in_ibrs_mode ( mode ) ) {
2023-01-24 16:33:18 +00:00
if ( boot_cpu_has ( X86_FEATURE_AUTOIBRS ) ) {
msr_set_bit ( MSR_EFER , _EFER_AUTOIBRS ) ;
} else {
x86_spec_ctrl_base | = SPEC_CTRL_IBRS ;
update_spec_ctrl ( x86_spec_ctrl_base ) ;
}
2022-02-16 19:57:01 +00:00
}
switch ( mode ) {
case SPECTRE_V2_NONE :
case SPECTRE_V2_EIBRS :
break ;
2022-06-14 21:15:55 +00:00
case SPECTRE_V2_IBRS :
setup_force_cpu_cap ( X86_FEATURE_KERNEL_IBRS ) ;
2022-07-14 23:15:35 +00:00
if ( boot_cpu_has ( X86_FEATURE_IBRS_ENHANCED ) )
pr_warn ( SPECTRE_V2_IBRS_PERF_MSG ) ;
2022-06-14 21:15:55 +00:00
break ;
2022-02-16 19:57:01 +00:00
case SPECTRE_V2_LFENCE :
case SPECTRE_V2_EIBRS_LFENCE :
2022-02-16 19:57:00 +00:00
setup_force_cpu_cap ( X86_FEATURE_RETPOLINE_LFENCE ) ;
2022-02-16 19:57:01 +00:00
fallthrough ;
case SPECTRE_V2_RETPOLINE :
case SPECTRE_V2_EIBRS_RETPOLINE :
2018-01-11 21:46:26 +00:00
setup_force_cpu_cap ( X86_FEATURE_RETPOLINE ) ;
2022-02-16 19:57:01 +00:00
break ;
2018-01-11 21:46:26 +00:00
}
2022-07-08 20:36:09 +00:00
/*
* Disable alternate RSB predictions in kernel when indirect CALLs and
* JMPs gets protection against BHI and Intramode - BTI , but RET
* prediction from a non - RSB predictor is still a risk .
*/
if ( mode = = SPECTRE_V2_EIBRS_LFENCE | |
mode = = SPECTRE_V2_EIBRS_RETPOLINE | |
mode = = SPECTRE_V2_RETPOLINE )
spec_ctrl_disable_kernel_rrsba ( ) ;
2018-01-11 21:46:26 +00:00
spectre_v2_enabled = mode ;
pr_info ( " %s \n " , spectre_v2_strings [ mode ] ) ;
2018-01-12 17:49:25 +00:00
/*
2022-06-14 21:16:15 +00:00
* If Spectre v2 protection has been enabled , fill the RSB during a
* context switch . In general there are two types of RSB attacks
* across context switches , for which the CALLs / RETs may be unbalanced .
2018-01-12 17:49:25 +00:00
*
2022-06-14 21:16:15 +00:00
* 1 ) RSB underflow
*
* Some Intel parts have " bottomless RSB " . When the RSB is empty ,
* speculated return targets may come from the branch predictor ,
* which could have a user - poisoned BTB or BHB entry .
*
* AMD has it even worse : * all * returns are speculated from the BTB ,
* regardless of the state of the RSB .
*
* When IBRS or eIBRS is enabled , the " user -> kernel " attack
* scenario is mitigated by the IBRS branch prediction isolation
* properties , so the RSB buffer filling wouldn ' t be necessary to
* protect against this type of attack .
*
* The " user -> user " attack scenario is mitigated by RSB filling .
*
* 2 ) Poisoned RSB entry
*
* If the ' next ' in - kernel return stack is shorter than ' prev ' ,
* ' next ' could be tricked into speculating with a user - poisoned RSB
* entry .
*
* The " user -> kernel " attack scenario is mitigated by SMEP and
* eIBRS .
*
* The " user -> user " scenario , also known as SpectreBHB , requires
* RSB clearing .
*
* So to mitigate all cases , unconditionally fill RSB on context
* switches .
*
* FIXME : Is this pointless for retbleed - affected AMD ?
2018-01-12 17:49:25 +00:00
*/
2018-07-26 11:14:55 +00:00
setup_force_cpu_cap ( X86_FEATURE_RSB_CTXSW ) ;
pr_info ( " Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch \n " ) ;
2018-01-25 16:14:15 +00:00
x86/speculation: Add RSB VM Exit protections
tl;dr: The Enhanced IBRS mitigation for Spectre v2 does not work as
documented for RET instructions after VM exits. Mitigate it with a new
one-entry RSB stuffing mechanism and a new LFENCE.
== Background ==
Indirect Branch Restricted Speculation (IBRS) was designed to help
mitigate Branch Target Injection and Speculative Store Bypass, i.e.
Spectre, attacks. IBRS prevents software run in less privileged modes
from affecting branch prediction in more privileged modes. IBRS requires
the MSR to be written on every privilege level change.
To overcome some of the performance issues of IBRS, Enhanced IBRS was
introduced. eIBRS is an "always on" IBRS, in other words, just turn
it on once instead of writing the MSR on every privilege level change.
When eIBRS is enabled, more privileged modes should be protected from
less privileged modes, including protecting VMMs from guests.
== Problem ==
Here's a simplification of how guests are run on Linux' KVM:
void run_kvm_guest(void)
{
// Prepare to run guest
VMRESUME();
// Clean up after guest runs
}
The execution flow for that would look something like this to the
processor:
1. Host-side: call run_kvm_guest()
2. Host-side: VMRESUME
3. Guest runs, does "CALL guest_function"
4. VM exit, host runs again
5. Host might make some "cleanup" function calls
6. Host-side: RET from run_kvm_guest()
Now, when back on the host, there are a couple of possible scenarios of
post-guest activity the host needs to do before executing host code:
* on pre-eIBRS hardware (legacy IBRS, or nothing at all), the RSB is not
touched and Linux has to do a 32-entry stuffing.
* on eIBRS hardware, VM exit with IBRS enabled, or restoring the host
IBRS=1 shortly after VM exit, has a documented side effect of flushing
the RSB except in this PBRSB situation where the software needs to stuff
the last RSB entry "by hand".
IOW, with eIBRS supported, host RET instructions should no longer be
influenced by guest behavior after the host retires a single CALL
instruction.
However, if the RET instructions are "unbalanced" with CALLs after a VM
exit as is the RET in #6, it might speculatively use the address for the
instruction after the CALL in #3 as an RSB prediction. This is a problem
since the (untrusted) guest controls this address.
Balanced CALL/RET instruction pairs such as in step #5 are not affected.
== Solution ==
The PBRSB issue affects a wide variety of Intel processors which
support eIBRS. But not all of them need mitigation. Today,
X86_FEATURE_RSB_VMEXIT triggers an RSB filling sequence that mitigates
PBRSB. Systems setting RSB_VMEXIT need no further mitigation - i.e.,
eIBRS systems which enable legacy IBRS explicitly.
However, such systems (X86_FEATURE_IBRS_ENHANCED) do not set RSB_VMEXIT
and most of them need a new mitigation.
Therefore, introduce a new feature flag X86_FEATURE_RSB_VMEXIT_LITE
which triggers a lighter-weight PBRSB mitigation versus RSB_VMEXIT.
The lighter-weight mitigation performs a CALL instruction which is
immediately followed by a speculative execution barrier (INT3). This
steers speculative execution to the barrier -- just like a retpoline
-- which ensures that speculation can never reach an unbalanced RET.
Then, ensure this CALL is retired before continuing execution with an
LFENCE.
In other words, the window of exposure is opened at VM exit where RET
behavior is troublesome. While the window is open, force RSB predictions
sampling for RET targets to a dead end at the INT3. Close the window
with the LFENCE.
There is a subset of eIBRS systems which are not vulnerable to PBRSB.
Add these systems to the cpu_vuln_whitelist[] as NO_EIBRS_PBRSB.
Future systems that aren't vulnerable will set ARCH_CAP_PBRSB_NO.
[ bp: Massage, incorporate review comments from Andy Cooper. ]
Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Co-developed-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
2022-08-02 22:47:01 +00:00
spectre_v2_determine_rsb_fill_type_at_vmexit ( mode ) ;
2022-06-14 21:16:15 +00:00
2018-02-19 10:50:54 +00:00
/*
2022-06-14 21:15:55 +00:00
* Retpoline protects the kernel , but doesn ' t protect firmware . IBRS
* and Enhanced IBRS protect firmware too , so enable IBRS around
2023-01-24 16:33:18 +00:00
* firmware calls only when IBRS / Enhanced / Automatic IBRS aren ' t
* otherwise enabled .
2018-08-01 18:42:25 +00:00
*
* Use " mode " to check Enhanced IBRS instead of boot_cpu_has ( ) , because
* the user might select retpoline on the kernel command line and if
* the CPU supports Enhanced IBRS , kernel might un - intentionally not
* enable IBRS around firmware calls .
2018-02-19 10:50:54 +00:00
*/
2022-07-18 11:41:37 +00:00
if ( boot_cpu_has_bug ( X86_BUG_RETBLEED ) & &
2022-07-28 12:26:02 +00:00
boot_cpu_has ( X86_FEATURE_IBPB ) & &
2022-07-18 11:41:37 +00:00
( boot_cpu_data . x86_vendor = = X86_VENDOR_AMD | |
boot_cpu_data . x86_vendor = = X86_VENDOR_HYGON ) ) {
if ( retbleed_cmd ! = RETBLEED_CMD_IBPB ) {
setup_force_cpu_cap ( X86_FEATURE_USE_IBPB_FW ) ;
pr_info ( " Enabling Speculation Barrier for firmware calls \n " ) ;
}
} else if ( boot_cpu_has ( X86_FEATURE_IBRS ) & & ! spectre_v2_in_ibrs_mode ( mode ) ) {
2018-02-19 10:50:54 +00:00
setup_force_cpu_cap ( X86_FEATURE_USE_IBRS_FW ) ;
pr_info ( " Enabling Restricted Speculation for firmware calls \n " ) ;
}
2018-09-25 12:38:55 +00:00
2018-11-25 18:33:45 +00:00
/* Set up IBPB and STIBP depending on the general spectre V2 command */
2022-06-14 21:15:56 +00:00
spectre_v2_cmd = cmd ;
2018-01-11 21:46:26 +00:00
}
2018-11-25 18:33:52 +00:00
static void update_stibp_msr ( void * __unused )
2018-11-25 18:33:41 +00:00
{
2022-06-14 21:16:07 +00:00
u64 val = spec_ctrl_current ( ) | ( x86_spec_ctrl_base & SPEC_CTRL_STIBP ) ;
2022-11-30 15:25:51 +00:00
update_spec_ctrl ( val ) ;
2018-11-25 18:33:41 +00:00
}
2018-11-25 18:33:52 +00:00
/* Update x86_spec_ctrl_base in case SMT state changed. */
static void update_stibp_strict ( void )
2018-11-25 18:33:41 +00:00
{
2018-11-25 18:33:52 +00:00
u64 mask = x86_spec_ctrl_base & ~ SPEC_CTRL_STIBP ;
if ( sched_smt_active ( ) )
mask | = SPEC_CTRL_STIBP ;
if ( mask = = x86_spec_ctrl_base )
return ;
pr_info ( " Update user space SMT mitigation: STIBP %s \n " ,
mask & SPEC_CTRL_STIBP ? " always-on " : " off " ) ;
x86_spec_ctrl_base = mask ;
on_each_cpu ( update_stibp_msr , NULL , 1 ) ;
2018-11-25 18:33:41 +00:00
}
2018-11-25 18:33:54 +00:00
/* Update the static key controlling the evaluation of TIF_SPEC_IB */
static void update_indir_branch_cond ( void )
{
if ( sched_smt_active ( ) )
static_branch_enable ( & switch_to_cond_stibp ) ;
else
static_branch_disable ( & switch_to_cond_stibp ) ;
}
2019-04-02 15:00:51 +00:00
# undef pr_fmt
# define pr_fmt(fmt) fmt
2019-02-18 21:04:08 +00:00
/* Update the static key controlling the MDS CPU buffer clear in idle */
static void update_mds_branch_idle ( void )
{
2022-05-20 03:31:12 +00:00
u64 ia32_cap = x86_read_arch_cap_msr ( ) ;
2019-02-18 21:04:08 +00:00
/*
* Enable the idle clearing if SMT is active on CPUs which are
* affected only by MSBDS and not any other MDS variant .
*
* The other variants cannot be mitigated when SMT is enabled , so
* clearing the buffers on idle just to prevent the Store Buffer
* repartitioning leak would be a window dressing exercise .
*/
if ( ! boot_cpu_has_bug ( X86_BUG_MSBDS_ONLY ) )
return ;
2022-05-20 03:31:12 +00:00
if ( sched_smt_active ( ) ) {
2019-02-18 21:04:08 +00:00
static_branch_enable ( & mds_idle_clear ) ;
2022-05-20 03:31:12 +00:00
} else if ( mmio_mitigation = = MMIO_MITIGATION_OFF | |
( ia32_cap & ARCH_CAP_FBSDP_NO ) ) {
2019-02-18 21:04:08 +00:00
static_branch_disable ( & mds_idle_clear ) ;
2022-05-20 03:31:12 +00:00
}
2019-02-18 21:04:08 +00:00
}
2019-04-02 15:00:51 +00:00
# define MDS_MSG_SMT "MDS CPU bug present and SMT on, data leak possible. See https: //www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details.\n"
2019-10-23 09:30:45 +00:00
# define TAA_MSG_SMT "TAA CPU bug present and SMT on, data leak possible. See https: //www.kernel.org/doc/html/latest/admin-guide/hw-vuln/tsx_async_abort.html for more details.\n"
2022-05-23 16:11:49 +00:00
# define MMIO_MSG_SMT "MMIO Stale Data CPU bug present and SMT on, data leak possible. See https: //www.kernel.org/doc/html/latest/admin-guide/hw-vuln/processor_mmio_stale_data.html for more details.\n"
2019-04-02 15:00:51 +00:00
2019-07-22 18:47:17 +00:00
void cpu_bugs_smt_update ( void )
2018-11-25 18:33:41 +00:00
{
mutex_lock ( & spec_ctrl_mutex ) ;
2022-02-25 22:32:28 +00:00
if ( sched_smt_active ( ) & & unprivileged_ebpf_enabled ( ) & &
spectre_v2_enabled = = SPECTRE_V2_EIBRS_LFENCE )
pr_warn_once ( SPECTRE_V2_EIBRS_LFENCE_EBPF_SMT_MSG ) ;
x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.
When STIBP is unavailable or enhanced IBRS is available, Linux
force-disables the IBPB mitigation of Spectre-BTB even when simultaneous
multithreading is disabled. While attempts to enable IBPB using
prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, ...) fail with
EPERM, the seccomp syscall (or its prctl(PR_SET_SECCOMP, ...) equivalent)
which are used e.g. by Chromium or OpenSSH succeed with no errors but the
application remains silently vulnerable to cross-process Spectre v2 attacks
(classical BTB poisoning). At the same time the SYSFS reporting
(/sys/devices/system/cpu/vulnerabilities/spectre_v2) displays that IBPB is
conditionally enabled when in fact it is unconditionally disabled.
STIBP is useful only when SMT is enabled. When SMT is disabled and STIBP is
unavailable, it makes no sense to force-disable also IBPB, because IBPB
protects against cross-process Spectre-BTB attacks regardless of the SMT
state. At the same time since missing STIBP was only observed on AMD CPUs,
AMD does not recommend using STIBP, but recommends using IBPB, so disabling
IBPB because of missing STIBP goes directly against AMD's advice:
https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf
Similarly, enhanced IBRS is designed to protect cross-core BTB poisoning
and BTB-poisoning attacks from user space against kernel (and
BTB-poisoning attacks from guest against hypervisor), it is not designed
to prevent cross-process (or cross-VM) BTB poisoning between processes (or
VMs) running on the same core. Therefore, even with enhanced IBRS it is
necessary to flush the BTB during context-switches, so there is no reason
to force disable IBPB when enhanced IBRS is available.
Enable the prctl control of IBPB even when STIBP is unavailable or enhanced
IBRS is available.
Fixes: 7cc765a67d8e ("x86/speculation: Enable prctl mode for spectre_v2_user")
Signed-off-by: Anthony Steinhauser <asteinhauser@google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
2020-05-19 13:40:42 +00:00
switch ( spectre_v2_user_stibp ) {
2018-11-25 18:33:52 +00:00
case SPECTRE_V2_USER_NONE :
break ;
case SPECTRE_V2_USER_STRICT :
2018-12-13 23:03:54 +00:00
case SPECTRE_V2_USER_STRICT_PREFERRED :
2018-11-25 18:33:52 +00:00
update_stibp_strict ( ) ;
break ;
x86/speculation: Add prctl() control for indirect branch speculation
Add the PR_SPEC_INDIRECT_BRANCH option for the PR_GET_SPECULATION_CTRL and
PR_SET_SPECULATION_CTRL prctls to allow fine grained per task control of
indirect branch speculation via STIBP and IBPB.
Invocations:
Check indirect branch speculation status with
- prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, 0, 0, 0);
Enable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE, 0, 0);
Disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE, 0, 0);
Force disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0);
See Documentation/userspace-api/spec_ctrl.rst.
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Casey Schaufler <casey.schaufler@intel.com>
Cc: Asit Mallick <asit.k.mallick@intel.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Jon Masters <jcm@redhat.com>
Cc: Waiman Long <longman9394@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Dave Stewart <david.c.stewart@intel.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20181125185005.866780996@linutronix.de
2018-11-25 18:33:53 +00:00
case SPECTRE_V2_USER_PRCTL :
2018-11-25 18:33:55 +00:00
case SPECTRE_V2_USER_SECCOMP :
2018-11-25 18:33:54 +00:00
update_indir_branch_cond ( ) ;
x86/speculation: Add prctl() control for indirect branch speculation
Add the PR_SPEC_INDIRECT_BRANCH option for the PR_GET_SPECULATION_CTRL and
PR_SET_SPECULATION_CTRL prctls to allow fine grained per task control of
indirect branch speculation via STIBP and IBPB.
Invocations:
Check indirect branch speculation status with
- prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, 0, 0, 0);
Enable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE, 0, 0);
Disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE, 0, 0);
Force disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0);
See Documentation/userspace-api/spec_ctrl.rst.
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Casey Schaufler <casey.schaufler@intel.com>
Cc: Asit Mallick <asit.k.mallick@intel.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Jon Masters <jcm@redhat.com>
Cc: Waiman Long <longman9394@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Dave Stewart <david.c.stewart@intel.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20181125185005.866780996@linutronix.de
2018-11-25 18:33:53 +00:00
break ;
2018-11-25 18:33:41 +00:00
}
2018-11-25 18:33:52 +00:00
2019-02-20 08:40:40 +00:00
switch ( mds_mitigation ) {
case MDS_MITIGATION_FULL :
case MDS_MITIGATION_VMWERV :
2019-04-02 15:00:51 +00:00
if ( sched_smt_active ( ) & & ! boot_cpu_has ( X86_BUG_MSBDS_ONLY ) )
pr_warn_once ( MDS_MSG_SMT ) ;
2019-02-18 21:04:08 +00:00
update_mds_branch_idle ( ) ;
2019-02-20 08:40:40 +00:00
break ;
case MDS_MITIGATION_OFF :
break ;
}
2019-02-18 21:04:08 +00:00
2019-10-23 09:30:45 +00:00
switch ( taa_mitigation ) {
case TAA_MITIGATION_VERW :
case TAA_MITIGATION_UCODE_NEEDED :
if ( sched_smt_active ( ) )
pr_warn_once ( TAA_MSG_SMT ) ;
break ;
case TAA_MITIGATION_TSX_DISABLED :
case TAA_MITIGATION_OFF :
break ;
}
2022-05-23 16:11:49 +00:00
switch ( mmio_mitigation ) {
case MMIO_MITIGATION_VERW :
case MMIO_MITIGATION_UCODE_NEEDED :
if ( sched_smt_active ( ) )
pr_warn_once ( MMIO_MSG_SMT ) ;
break ;
case MMIO_MITIGATION_OFF :
break ;
}
2018-11-25 18:33:41 +00:00
mutex_unlock ( & spec_ctrl_mutex ) ;
}
2018-04-26 02:04:21 +00:00
# undef pr_fmt
# define pr_fmt(fmt) "Speculative Store Bypass: " fmt
2018-05-03 22:03:30 +00:00
static enum ssb_mitigation ssb_mode __ro_after_init = SPEC_STORE_BYPASS_NONE ;
2018-04-26 02:04:21 +00:00
/* The kernel command line selection */
enum ssb_mitigation_cmd {
SPEC_STORE_BYPASS_CMD_NONE ,
SPEC_STORE_BYPASS_CMD_AUTO ,
SPEC_STORE_BYPASS_CMD_ON ,
2018-04-29 13:26:40 +00:00
SPEC_STORE_BYPASS_CMD_PRCTL ,
2018-05-03 21:37:54 +00:00
SPEC_STORE_BYPASS_CMD_SECCOMP ,
2018-04-26 02:04:21 +00:00
} ;
2018-11-25 18:33:42 +00:00
static const char * const ssb_strings [ ] = {
2018-04-26 02:04:21 +00:00
[ SPEC_STORE_BYPASS_NONE ] = " Vulnerable " ,
2018-04-29 13:26:40 +00:00
[ SPEC_STORE_BYPASS_DISABLE ] = " Mitigation: Speculative Store Bypass disabled " ,
2018-05-03 21:37:54 +00:00
[ SPEC_STORE_BYPASS_PRCTL ] = " Mitigation: Speculative Store Bypass disabled via prctl " ,
[ SPEC_STORE_BYPASS_SECCOMP ] = " Mitigation: Speculative Store Bypass disabled via prctl and seccomp " ,
2018-04-26 02:04:21 +00:00
} ;
static const struct {
const char * option ;
enum ssb_mitigation_cmd cmd ;
2019-03-30 00:47:43 +00:00
} ssb_mitigation_options [ ] __initconst = {
2018-05-03 21:37:54 +00:00
{ " auto " , SPEC_STORE_BYPASS_CMD_AUTO } , /* Platform decides */
{ " on " , SPEC_STORE_BYPASS_CMD_ON } , /* Disable Speculative Store Bypass */
{ " off " , SPEC_STORE_BYPASS_CMD_NONE } , /* Don't touch Speculative Store Bypass */
{ " prctl " , SPEC_STORE_BYPASS_CMD_PRCTL } , /* Disable Speculative Store Bypass via prctl */
{ " seccomp " , SPEC_STORE_BYPASS_CMD_SECCOMP } , /* Disable Speculative Store Bypass via prctl and seccomp */
2018-04-26 02:04:21 +00:00
} ;
static enum ssb_mitigation_cmd __init ssb_parse_cmdline ( void )
{
enum ssb_mitigation_cmd cmd = SPEC_STORE_BYPASS_CMD_AUTO ;
char arg [ 20 ] ;
int ret , i ;
2019-04-12 20:39:29 +00:00
if ( cmdline_find_option_bool ( boot_command_line , " nospec_store_bypass_disable " ) | |
cpu_mitigations_off ( ) ) {
2018-04-26 02:04:21 +00:00
return SPEC_STORE_BYPASS_CMD_NONE ;
} else {
ret = cmdline_find_option ( boot_command_line , " spec_store_bypass_disable " ,
arg , sizeof ( arg ) ) ;
if ( ret < 0 )
return SPEC_STORE_BYPASS_CMD_AUTO ;
for ( i = 0 ; i < ARRAY_SIZE ( ssb_mitigation_options ) ; i + + ) {
if ( ! match_option ( arg , ret , ssb_mitigation_options [ i ] . option ) )
continue ;
cmd = ssb_mitigation_options [ i ] . cmd ;
break ;
}
if ( i > = ARRAY_SIZE ( ssb_mitigation_options ) ) {
pr_err ( " unknown option (%s). Switching to AUTO select \n " , arg ) ;
return SPEC_STORE_BYPASS_CMD_AUTO ;
}
}
return cmd ;
}
2018-05-10 20:47:18 +00:00
static enum ssb_mitigation __init __ssb_select_mitigation ( void )
2018-04-26 02:04:21 +00:00
{
enum ssb_mitigation mode = SPEC_STORE_BYPASS_NONE ;
enum ssb_mitigation_cmd cmd ;
2018-05-09 19:41:38 +00:00
if ( ! boot_cpu_has ( X86_FEATURE_SSBD ) )
2018-04-26 02:04:21 +00:00
return mode ;
cmd = ssb_parse_cmdline ( ) ;
if ( ! boot_cpu_has_bug ( X86_BUG_SPEC_STORE_BYPASS ) & &
( cmd = = SPEC_STORE_BYPASS_CMD_NONE | |
cmd = = SPEC_STORE_BYPASS_CMD_AUTO ) )
return mode ;
switch ( cmd ) {
2018-05-03 21:37:54 +00:00
case SPEC_STORE_BYPASS_CMD_SECCOMP :
/*
* Choose prctl + seccomp as the default mode if seccomp is
* enabled .
*/
if ( IS_ENABLED ( CONFIG_SECCOMP ) )
mode = SPEC_STORE_BYPASS_SECCOMP ;
else
mode = SPEC_STORE_BYPASS_PRCTL ;
2018-04-29 13:26:40 +00:00
break ;
2018-04-26 02:04:21 +00:00
case SPEC_STORE_BYPASS_CMD_ON :
mode = SPEC_STORE_BYPASS_DISABLE ;
break ;
x86: change default to spec_store_bypass_disable=prctl spectre_v2_user=prctl
Switch the kernel default of SSBD and STIBP to the ones with
CONFIG_SECCOMP=n (i.e. spec_store_bypass_disable=prctl
spectre_v2_user=prctl) even if CONFIG_SECCOMP=y.
Several motivations listed below:
- If SMT is enabled the seccomp jail can still attack the rest of the
system even with spectre_v2_user=seccomp by using MDS-HT (except on
XEON PHI where MDS can be tamed with SMT left enabled, but that's a
special case). Setting STIBP become a very expensive window dressing
after MDS-HT was discovered.
- The seccomp jail cannot attack the kernel with spectre-v2-HT
regardless (even if STIBP is not set), but with MDS-HT the seccomp
jail can attack the kernel too.
- With spec_store_bypass_disable=prctl the seccomp jail can attack the
other userland (guest or host mode) using spectre-v2-HT, but the
userland attack is already mitigated by both ASLR and pid namespaces
for host userland and through virt isolation with libkrun or
kata. (if something if somebody is worried about spectre-v2-HT it's
best to mount proc with hidepid=2,gid=proc on workstations where not
all apps may run under container runtimes, rather than slowing down
all seccomp jails, but the best is to add pid namespaces to the
seccomp jail). As opposed MDS-HT is not mitigated and the seccomp
jail can still attack all other host and guest userland if SMT is
enabled even with spec_store_bypass_disable=seccomp.
- If full security is required then MDS-HT must also be mitigated with
nosmt and then spectre_v2_user=prctl and spectre_v2_user=seccomp
would become identical.
- Setting spectre_v2_user=seccomp is overall lower priority than to
setting javascript.options.wasm false in about:config to protect
against remote wasm MDS-HT, instead of worrying about Spectre-v2-HT
and STIBP which again is already statistically well mitigated by
other means in userland and it's fully mitigated in kernel with
retpolines (unlike the wasm assist call with MDS-HT).
- SSBD is needed to prevent reading the JIT memory and the primary
user being the OpenJDK. However the primary user of SSBD wouldn't be
covered by spec_store_bypass_disable=seccomp because it doesn't use
seccomp and the primary user also explicitly declined to set
PR_SET_SPECULATION_CTRL+PR_SPEC_STORE_BYPASS despite it easily
could. In fact it would need to set it only when the sandboxing
mechanism is enabled for javaws applets, but it still declined it by
declaring security within the same user address space as an
untenable objective for their JIT, even in the sandboxing case where
performance would be a lesser concern (for the record: I kind of
disagree in not setting PR_SPEC_STORE_BYPASS in the sandbox case and
I prefer to run javaws through a wrapper that sets
PR_SPEC_STORE_BYPASS if I need). In turn it can be inferred that
even if the primary user of SSBD would use seccomp, they would
invoke it with SECCOMP_FILTER_FLAG_SPEC_ALLOW by now.
- runc/crun already set SECCOMP_FILTER_FLAG_SPEC_ALLOW by default, k8s
and podman have a default json seccomp allowlist that cannot be
slowed down, so for the #1 seccomp user this change is already a
noop.
- systemd/sshd or other apps that use seccomp, if they really need
STIBP or SSBD, they need to explicitly set the
PR_SET_SPECULATION_CTRL by now. The stibp/ssbd seccomp blind
catch-all approach was done probably initially with a wishful
thinking objective to pretend to have a peace of mind that it could
magically fix it all. That was wishful thinking before MDS-HT was
discovered, but after MDS-HT has been discovered it become just
window dressing.
- For qemu "-sandbox" seccomp jail it wouldn't make sense to set STIBP
or SSBD. SSBD doesn't help with KVM because there's no JIT (if it's
needed with TCG it should be an opt-in with
PR_SET_SPECULATION_CTRL+PR_SPEC_STORE_BYPASS and it shouldn't
slowdown KVM for nothing). For qemu+KVM STIBP would be even more
window dressing than it is for all other apps, because in the
qemu+KVM case there's not only the MDS attack to worry about with
SMT enabled. Even after disabling SMT, there's still a theoretical
spectre-v2 attack possible within the same thread context from guest
mode to host ring3 that the host kernel retpoline mitigation has no
theoretical chance to mitigate. On some kernels a
ibrs-always/ibrs-retpoline opt-in model is provided that will
enabled IBRS in the qemu host ring3 userland which fixes this
theoretical concern. Only after enabling IBRS in the host userland
it would then make sense to proceed and worry about STIBP and an
attack on the other host userland, but then again SMT would need to
be disabled for full security anyway, so that would render STIBP
again a noop.
- last but not the least: the lack of "spec_store_bypass_disable=prctl
spectre_v2_user=prctl" means the moment a guest boots and
sshd/systemd runs, the guest kernel will write to SPEC_CTRL MSR
which will make the guest vmexit forever slower, forcing KVM to
issue a very slow rdmsr instruction at every vmexit. So the end
result is that SPEC_CTRL MSR is only available in GCE. Most other
public cloud providers don't expose SPEC_CTRL, which means that not
only STIBP/SSBD isn't available, but IBPB isn't available either
(which would cause no overhead to the guest or the hypervisor
because it's write only and requires no reading during vmexit). So
the current default already net loss in security (missing IBPB)
which means most public cloud providers cannot achieve a fully
secure guest with nosmt (and nosmt is enough to fully mitigate
MDS-HT). It also means GCE and is unfairly penalized in performance
because it provides the option to enable full security in the guest
as an opt-in (i.e. nosmt and IBPB). So this change will allow all
cloud providers to expose SPEC_CTRL without incurring into any
hypervisor slowdown and at the same time it will remove the unfair
penalization of GCE performance for doing the right thing and it'll
allow to get full security with nosmt with IBPB being available (and
STIBP becoming meaningless).
Example to put things in prospective: the STIBP enabled in seccomp has
never been about protecting apps using seccomp like sshd from an
attack from a malicious userland, but to the contrary it has always
been about protecting the system from an attack from sshd, after a
successful remote network exploit against sshd. In fact initially it
wasn't obvious STIBP would work both ways (STIBP was about preventing
the task that runs with STIBP to be attacked with spectre-v2-HT, but
accidentally in the STIBP case it also prevents the attack in the
other direction). In the hypothetical case that sshd has been remotely
exploited the last concern should be STIBP being set, because it'll be
still possible to obtain info even from the kernel by using MDS if
nosmt wasn't set (and if it was set, STIBP is a noop in the first
place). As opposed kernel cannot leak anything with spectre-v2 HT
because of retpolines and the userland is mitigated by ASLR already
and ideally PID namespaces too. If something it'd be worth checking if
sshd run the seccomp thread under pid namespaces too if available in
the running kernel. SSBD also would be a noop for sshd, since sshd
uses no JIT. If sshd prefers to keep doing the STIBP window dressing
exercise, it still can even after this change of defaults by opting-in
with PR_SPEC_INDIRECT_BRANCH.
Ultimately setting SSBD and STIBP by default for all seccomp jails is
a bad sweet spot and bad default with more cons than pros that end up
reducing security in the public cloud (by giving an huge incentive to
not expose SPEC_CTRL which would be needed to get full security with
IBPB after setting nosmt in the guest) and by excessively hurting
performance to more secure apps using seccomp that end up having to
opt out with SECCOMP_FILTER_FLAG_SPEC_ALLOW.
The following is the verified result of the new default with SMT
enabled:
(gdb) print spectre_v2_user_stibp
$1 = SPECTRE_V2_USER_PRCTL
(gdb) print spectre_v2_user_ibpb
$2 = SPECTRE_V2_USER_PRCTL
(gdb) print ssb_mode
$3 = SPEC_STORE_BYPASS_PRCTL
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20201104235054.5678-1-aarcange@redhat.com
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Link: https://lore.kernel.org/lkml/AAA2EF2C-293D-4D5B-BFA6-FF655105CD84@redhat.com
Acked-by: Waiman Long <longman@redhat.com>
Link: https://lore.kernel.org/lkml/c0722838-06f7-da6b-138f-e0f26362f16a@redhat.com
2020-11-04 23:50:54 +00:00
case SPEC_STORE_BYPASS_CMD_AUTO :
2018-04-29 13:26:40 +00:00
case SPEC_STORE_BYPASS_CMD_PRCTL :
mode = SPEC_STORE_BYPASS_PRCTL ;
break ;
2018-04-26 02:04:21 +00:00
case SPEC_STORE_BYPASS_CMD_NONE :
break ;
}
2018-04-26 02:04:22 +00:00
/*
* We have three CPU feature flags that are in play here :
* - X86_BUG_SPEC_STORE_BYPASS - CPU is susceptible .
2018-05-09 19:41:38 +00:00
* - X86_FEATURE_SSBD - CPU is able to turn off speculative store bypass
2018-04-26 02:04:22 +00:00
* - X86_FEATURE_SPEC_STORE_BYPASS_DISABLE - engage the mitigation
*/
2018-04-29 13:26:40 +00:00
if ( mode = = SPEC_STORE_BYPASS_DISABLE ) {
2018-04-26 02:04:21 +00:00
setup_force_cpu_cap ( X86_FEATURE_SPEC_STORE_BYPASS_DISABLE ) ;
2018-04-26 02:04:22 +00:00
/*
2018-06-01 14:59:20 +00:00
* Intel uses the SPEC CTRL MSR Bit ( 2 ) for this , while AMD may
* use a completely different MSR and bit dependent on family .
2018-04-26 02:04:22 +00:00
*/
2018-07-02 21:36:02 +00:00
if ( ! static_cpu_has ( X86_FEATURE_SPEC_CTRL_SSBD ) & &
! static_cpu_has ( X86_FEATURE_AMD_SSBD ) ) {
2018-06-01 14:59:21 +00:00
x86_amd_ssb_disable ( ) ;
2018-07-02 21:36:02 +00:00
} else {
2018-05-09 19:41:38 +00:00
x86_spec_ctrl_base | = SPEC_CTRL_SSBD ;
2022-11-30 15:25:51 +00:00
update_spec_ctrl ( x86_spec_ctrl_base ) ;
2018-04-26 02:04:22 +00:00
}
}
2018-04-26 02:04:21 +00:00
return mode ;
}
2018-05-11 20:50:35 +00:00
static void ssb_select_mitigation ( void )
2018-04-26 02:04:21 +00:00
{
ssb_mode = __ssb_select_mitigation ( ) ;
if ( boot_cpu_has_bug ( X86_BUG_SPEC_STORE_BYPASS ) )
pr_info ( " %s \n " , ssb_strings [ ssb_mode ] ) ;
}
2018-01-11 21:46:26 +00:00
# undef pr_fmt
2018-05-03 21:37:54 +00:00
# define pr_fmt(fmt) "Speculation prctl: " fmt
2018-01-11 21:46:26 +00:00
2018-11-28 09:56:57 +00:00
static void task_update_spec_tif ( struct task_struct * tsk )
2018-04-29 13:26:40 +00:00
{
2018-11-28 09:56:57 +00:00
/* Force the update of the real TIF bits */
set_tsk_thread_flag ( tsk , TIF_SPEC_FORCE_UPDATE ) ;
2018-11-25 18:33:51 +00:00
/*
* Immediately update the speculation control MSRs for the current
* task , but for a non - current task delay setting the CPU
* mitigation until it is scheduled next .
*
* This can only happen for SECCOMP mitigation . For PRCTL it ' s
* always the current task .
*/
2018-11-28 09:56:57 +00:00
if ( tsk = = current )
2018-11-25 18:33:51 +00:00
speculation_ctrl_update_current ( ) ;
}
2021-01-08 12:10:55 +00:00
static int l1d_flush_prctl_set ( struct task_struct * task , unsigned long ctrl )
{
if ( ! static_branch_unlikely ( & switch_mm_cond_l1d_flush ) )
return - EPERM ;
switch ( ctrl ) {
case PR_SPEC_ENABLE :
set_ti_thread_flag ( & task - > thread_info , TIF_SPEC_L1D_FLUSH ) ;
return 0 ;
case PR_SPEC_DISABLE :
clear_ti_thread_flag ( & task - > thread_info , TIF_SPEC_L1D_FLUSH ) ;
return 0 ;
default :
return - ERANGE ;
}
}
2018-11-25 18:33:51 +00:00
static int ssb_prctl_set ( struct task_struct * task , unsigned long ctrl )
{
2018-05-03 21:37:54 +00:00
if ( ssb_mode ! = SPEC_STORE_BYPASS_PRCTL & &
ssb_mode ! = SPEC_STORE_BYPASS_SECCOMP )
2018-04-29 13:26:40 +00:00
return - ENXIO ;
2018-05-03 20:09:15 +00:00
switch ( ctrl ) {
case PR_SPEC_ENABLE :
/* If speculation is force disabled, enable is not allowed */
if ( task_spec_ssb_force_disable ( task ) )
return - EPERM ;
task_clear_spec_ssb_disable ( task ) ;
2019-01-16 22:01:36 +00:00
task_clear_spec_ssb_noexec ( task ) ;
2018-11-28 09:56:57 +00:00
task_update_spec_tif ( task ) ;
2018-05-03 20:09:15 +00:00
break ;
case PR_SPEC_DISABLE :
task_set_spec_ssb_disable ( task ) ;
2019-01-16 22:01:36 +00:00
task_clear_spec_ssb_noexec ( task ) ;
2018-11-28 09:56:57 +00:00
task_update_spec_tif ( task ) ;
2018-05-03 20:09:15 +00:00
break ;
case PR_SPEC_FORCE_DISABLE :
task_set_spec_ssb_disable ( task ) ;
task_set_spec_ssb_force_disable ( task ) ;
2019-01-16 22:01:36 +00:00
task_clear_spec_ssb_noexec ( task ) ;
task_update_spec_tif ( task ) ;
break ;
case PR_SPEC_DISABLE_NOEXEC :
if ( task_spec_ssb_force_disable ( task ) )
return - EPERM ;
task_set_spec_ssb_disable ( task ) ;
task_set_spec_ssb_noexec ( task ) ;
2018-11-28 09:56:57 +00:00
task_update_spec_tif ( task ) ;
2018-05-03 20:09:15 +00:00
break ;
default :
return - ERANGE ;
}
2018-04-29 13:26:40 +00:00
return 0 ;
}
x86/speculation: Allow IBPB to be conditionally enabled on CPUs with always-on STIBP
On AMD CPUs which have the feature X86_FEATURE_AMD_STIBP_ALWAYS_ON,
STIBP is set to on and
spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT_PREFERRED
At the same time, IBPB can be set to conditional.
However, this leads to the case where it's impossible to turn on IBPB
for a process because in the PR_SPEC_DISABLE case in ib_prctl_set() the
spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT_PREFERRED
condition leads to a return before the task flag is set. Similarly,
ib_prctl_get() will return PR_SPEC_DISABLE even though IBPB is set to
conditional.
More generally, the following cases are possible:
1. STIBP = conditional && IBPB = on for spectre_v2_user=seccomp,ibpb
2. STIBP = on && IBPB = conditional for AMD CPUs with
X86_FEATURE_AMD_STIBP_ALWAYS_ON
The first case functions correctly today, but only because
spectre_v2_user_ibpb isn't updated to reflect the IBPB mode.
At a high level, this change does one thing. If either STIBP or IBPB
is set to conditional, allow the prctl to change the task flag.
Also, reflect that capability when querying the state. This isn't
perfect since it doesn't take into account if only STIBP or IBPB is
unconditionally on. But it allows the conditional feature to work as
expected, without affecting the unconditional one.
[ bp: Massage commit message and comment; space out statements for
better readability. ]
Fixes: 21998a351512 ("x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.")
Signed-off-by: Anand K Mistry <amistry@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lkml.kernel.org/r/20201105163246.v2.1.Ifd7243cd3e2c2206a893ad0a5b9a4f19549e22c6@changeid
2020-11-05 05:33:04 +00:00
static bool is_spec_ib_user_controlled ( void )
{
return spectre_v2_user_ibpb = = SPECTRE_V2_USER_PRCTL | |
spectre_v2_user_ibpb = = SPECTRE_V2_USER_SECCOMP | |
spectre_v2_user_stibp = = SPECTRE_V2_USER_PRCTL | |
spectre_v2_user_stibp = = SPECTRE_V2_USER_SECCOMP ;
}
x86/speculation: Add prctl() control for indirect branch speculation
Add the PR_SPEC_INDIRECT_BRANCH option for the PR_GET_SPECULATION_CTRL and
PR_SET_SPECULATION_CTRL prctls to allow fine grained per task control of
indirect branch speculation via STIBP and IBPB.
Invocations:
Check indirect branch speculation status with
- prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, 0, 0, 0);
Enable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE, 0, 0);
Disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE, 0, 0);
Force disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0);
See Documentation/userspace-api/spec_ctrl.rst.
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Casey Schaufler <casey.schaufler@intel.com>
Cc: Asit Mallick <asit.k.mallick@intel.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Jon Masters <jcm@redhat.com>
Cc: Waiman Long <longman9394@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Dave Stewart <david.c.stewart@intel.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20181125185005.866780996@linutronix.de
2018-11-25 18:33:53 +00:00
static int ib_prctl_set ( struct task_struct * task , unsigned long ctrl )
{
switch ( ctrl ) {
case PR_SPEC_ENABLE :
x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.
When STIBP is unavailable or enhanced IBRS is available, Linux
force-disables the IBPB mitigation of Spectre-BTB even when simultaneous
multithreading is disabled. While attempts to enable IBPB using
prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, ...) fail with
EPERM, the seccomp syscall (or its prctl(PR_SET_SECCOMP, ...) equivalent)
which are used e.g. by Chromium or OpenSSH succeed with no errors but the
application remains silently vulnerable to cross-process Spectre v2 attacks
(classical BTB poisoning). At the same time the SYSFS reporting
(/sys/devices/system/cpu/vulnerabilities/spectre_v2) displays that IBPB is
conditionally enabled when in fact it is unconditionally disabled.
STIBP is useful only when SMT is enabled. When SMT is disabled and STIBP is
unavailable, it makes no sense to force-disable also IBPB, because IBPB
protects against cross-process Spectre-BTB attacks regardless of the SMT
state. At the same time since missing STIBP was only observed on AMD CPUs,
AMD does not recommend using STIBP, but recommends using IBPB, so disabling
IBPB because of missing STIBP goes directly against AMD's advice:
https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf
Similarly, enhanced IBRS is designed to protect cross-core BTB poisoning
and BTB-poisoning attacks from user space against kernel (and
BTB-poisoning attacks from guest against hypervisor), it is not designed
to prevent cross-process (or cross-VM) BTB poisoning between processes (or
VMs) running on the same core. Therefore, even with enhanced IBRS it is
necessary to flush the BTB during context-switches, so there is no reason
to force disable IBPB when enhanced IBRS is available.
Enable the prctl control of IBPB even when STIBP is unavailable or enhanced
IBRS is available.
Fixes: 7cc765a67d8e ("x86/speculation: Enable prctl mode for spectre_v2_user")
Signed-off-by: Anthony Steinhauser <asteinhauser@google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
2020-05-19 13:40:42 +00:00
if ( spectre_v2_user_ibpb = = SPECTRE_V2_USER_NONE & &
spectre_v2_user_stibp = = SPECTRE_V2_USER_NONE )
x86/speculation: Add prctl() control for indirect branch speculation
Add the PR_SPEC_INDIRECT_BRANCH option for the PR_GET_SPECULATION_CTRL and
PR_SET_SPECULATION_CTRL prctls to allow fine grained per task control of
indirect branch speculation via STIBP and IBPB.
Invocations:
Check indirect branch speculation status with
- prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, 0, 0, 0);
Enable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE, 0, 0);
Disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE, 0, 0);
Force disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0);
See Documentation/userspace-api/spec_ctrl.rst.
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Casey Schaufler <casey.schaufler@intel.com>
Cc: Asit Mallick <asit.k.mallick@intel.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Jon Masters <jcm@redhat.com>
Cc: Waiman Long <longman9394@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Dave Stewart <david.c.stewart@intel.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20181125185005.866780996@linutronix.de
2018-11-25 18:33:53 +00:00
return 0 ;
x86/speculation: Allow IBPB to be conditionally enabled on CPUs with always-on STIBP
On AMD CPUs which have the feature X86_FEATURE_AMD_STIBP_ALWAYS_ON,
STIBP is set to on and
spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT_PREFERRED
At the same time, IBPB can be set to conditional.
However, this leads to the case where it's impossible to turn on IBPB
for a process because in the PR_SPEC_DISABLE case in ib_prctl_set() the
spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT_PREFERRED
condition leads to a return before the task flag is set. Similarly,
ib_prctl_get() will return PR_SPEC_DISABLE even though IBPB is set to
conditional.
More generally, the following cases are possible:
1. STIBP = conditional && IBPB = on for spectre_v2_user=seccomp,ibpb
2. STIBP = on && IBPB = conditional for AMD CPUs with
X86_FEATURE_AMD_STIBP_ALWAYS_ON
The first case functions correctly today, but only because
spectre_v2_user_ibpb isn't updated to reflect the IBPB mode.
At a high level, this change does one thing. If either STIBP or IBPB
is set to conditional, allow the prctl to change the task flag.
Also, reflect that capability when querying the state. This isn't
perfect since it doesn't take into account if only STIBP or IBPB is
unconditionally on. But it allows the conditional feature to work as
expected, without affecting the unconditional one.
[ bp: Massage commit message and comment; space out statements for
better readability. ]
Fixes: 21998a351512 ("x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.")
Signed-off-by: Anand K Mistry <amistry@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lkml.kernel.org/r/20201105163246.v2.1.Ifd7243cd3e2c2206a893ad0a5b9a4f19549e22c6@changeid
2020-11-05 05:33:04 +00:00
x86/speculation: Add prctl() control for indirect branch speculation
Add the PR_SPEC_INDIRECT_BRANCH option for the PR_GET_SPECULATION_CTRL and
PR_SET_SPECULATION_CTRL prctls to allow fine grained per task control of
indirect branch speculation via STIBP and IBPB.
Invocations:
Check indirect branch speculation status with
- prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, 0, 0, 0);
Enable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE, 0, 0);
Disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE, 0, 0);
Force disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0);
See Documentation/userspace-api/spec_ctrl.rst.
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Casey Schaufler <casey.schaufler@intel.com>
Cc: Asit Mallick <asit.k.mallick@intel.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Jon Masters <jcm@redhat.com>
Cc: Waiman Long <longman9394@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Dave Stewart <david.c.stewart@intel.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20181125185005.866780996@linutronix.de
2018-11-25 18:33:53 +00:00
/*
x86/speculation: Allow IBPB to be conditionally enabled on CPUs with always-on STIBP
On AMD CPUs which have the feature X86_FEATURE_AMD_STIBP_ALWAYS_ON,
STIBP is set to on and
spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT_PREFERRED
At the same time, IBPB can be set to conditional.
However, this leads to the case where it's impossible to turn on IBPB
for a process because in the PR_SPEC_DISABLE case in ib_prctl_set() the
spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT_PREFERRED
condition leads to a return before the task flag is set. Similarly,
ib_prctl_get() will return PR_SPEC_DISABLE even though IBPB is set to
conditional.
More generally, the following cases are possible:
1. STIBP = conditional && IBPB = on for spectre_v2_user=seccomp,ibpb
2. STIBP = on && IBPB = conditional for AMD CPUs with
X86_FEATURE_AMD_STIBP_ALWAYS_ON
The first case functions correctly today, but only because
spectre_v2_user_ibpb isn't updated to reflect the IBPB mode.
At a high level, this change does one thing. If either STIBP or IBPB
is set to conditional, allow the prctl to change the task flag.
Also, reflect that capability when querying the state. This isn't
perfect since it doesn't take into account if only STIBP or IBPB is
unconditionally on. But it allows the conditional feature to work as
expected, without affecting the unconditional one.
[ bp: Massage commit message and comment; space out statements for
better readability. ]
Fixes: 21998a351512 ("x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.")
Signed-off-by: Anand K Mistry <amistry@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lkml.kernel.org/r/20201105163246.v2.1.Ifd7243cd3e2c2206a893ad0a5b9a4f19549e22c6@changeid
2020-11-05 05:33:04 +00:00
* With strict mode for both IBPB and STIBP , the instruction
* code paths avoid checking this task flag and instead ,
* unconditionally run the instruction . However , STIBP and IBPB
* are independent and either can be set to conditionally
* enabled regardless of the mode of the other .
*
* If either is set to conditional , allow the task flag to be
* updated , unless it was force - disabled by a previous prctl
* call . Currently , this is possible on an AMD CPU which has the
* feature X86_FEATURE_AMD_STIBP_ALWAYS_ON . In this case , if the
* kernel is booted with ' spectre_v2_user = seccomp ' , then
* spectre_v2_user_ibpb = = SPECTRE_V2_USER_SECCOMP and
* spectre_v2_user_stibp = = SPECTRE_V2_USER_STRICT_PREFERRED .
x86/speculation: Add prctl() control for indirect branch speculation
Add the PR_SPEC_INDIRECT_BRANCH option for the PR_GET_SPECULATION_CTRL and
PR_SET_SPECULATION_CTRL prctls to allow fine grained per task control of
indirect branch speculation via STIBP and IBPB.
Invocations:
Check indirect branch speculation status with
- prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, 0, 0, 0);
Enable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE, 0, 0);
Disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE, 0, 0);
Force disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0);
See Documentation/userspace-api/spec_ctrl.rst.
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Casey Schaufler <casey.schaufler@intel.com>
Cc: Asit Mallick <asit.k.mallick@intel.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Jon Masters <jcm@redhat.com>
Cc: Waiman Long <longman9394@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Dave Stewart <david.c.stewart@intel.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20181125185005.866780996@linutronix.de
2018-11-25 18:33:53 +00:00
*/
x86/speculation: Allow IBPB to be conditionally enabled on CPUs with always-on STIBP
On AMD CPUs which have the feature X86_FEATURE_AMD_STIBP_ALWAYS_ON,
STIBP is set to on and
spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT_PREFERRED
At the same time, IBPB can be set to conditional.
However, this leads to the case where it's impossible to turn on IBPB
for a process because in the PR_SPEC_DISABLE case in ib_prctl_set() the
spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT_PREFERRED
condition leads to a return before the task flag is set. Similarly,
ib_prctl_get() will return PR_SPEC_DISABLE even though IBPB is set to
conditional.
More generally, the following cases are possible:
1. STIBP = conditional && IBPB = on for spectre_v2_user=seccomp,ibpb
2. STIBP = on && IBPB = conditional for AMD CPUs with
X86_FEATURE_AMD_STIBP_ALWAYS_ON
The first case functions correctly today, but only because
spectre_v2_user_ibpb isn't updated to reflect the IBPB mode.
At a high level, this change does one thing. If either STIBP or IBPB
is set to conditional, allow the prctl to change the task flag.
Also, reflect that capability when querying the state. This isn't
perfect since it doesn't take into account if only STIBP or IBPB is
unconditionally on. But it allows the conditional feature to work as
expected, without affecting the unconditional one.
[ bp: Massage commit message and comment; space out statements for
better readability. ]
Fixes: 21998a351512 ("x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.")
Signed-off-by: Anand K Mistry <amistry@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lkml.kernel.org/r/20201105163246.v2.1.Ifd7243cd3e2c2206a893ad0a5b9a4f19549e22c6@changeid
2020-11-05 05:33:04 +00:00
if ( ! is_spec_ib_user_controlled ( ) | |
2020-06-07 12:44:19 +00:00
task_spec_ib_force_disable ( task ) )
x86/speculation: Add prctl() control for indirect branch speculation
Add the PR_SPEC_INDIRECT_BRANCH option for the PR_GET_SPECULATION_CTRL and
PR_SET_SPECULATION_CTRL prctls to allow fine grained per task control of
indirect branch speculation via STIBP and IBPB.
Invocations:
Check indirect branch speculation status with
- prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, 0, 0, 0);
Enable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE, 0, 0);
Disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE, 0, 0);
Force disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0);
See Documentation/userspace-api/spec_ctrl.rst.
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Casey Schaufler <casey.schaufler@intel.com>
Cc: Asit Mallick <asit.k.mallick@intel.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Jon Masters <jcm@redhat.com>
Cc: Waiman Long <longman9394@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Dave Stewart <david.c.stewart@intel.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20181125185005.866780996@linutronix.de
2018-11-25 18:33:53 +00:00
return - EPERM ;
x86/speculation: Allow IBPB to be conditionally enabled on CPUs with always-on STIBP
On AMD CPUs which have the feature X86_FEATURE_AMD_STIBP_ALWAYS_ON,
STIBP is set to on and
spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT_PREFERRED
At the same time, IBPB can be set to conditional.
However, this leads to the case where it's impossible to turn on IBPB
for a process because in the PR_SPEC_DISABLE case in ib_prctl_set() the
spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT_PREFERRED
condition leads to a return before the task flag is set. Similarly,
ib_prctl_get() will return PR_SPEC_DISABLE even though IBPB is set to
conditional.
More generally, the following cases are possible:
1. STIBP = conditional && IBPB = on for spectre_v2_user=seccomp,ibpb
2. STIBP = on && IBPB = conditional for AMD CPUs with
X86_FEATURE_AMD_STIBP_ALWAYS_ON
The first case functions correctly today, but only because
spectre_v2_user_ibpb isn't updated to reflect the IBPB mode.
At a high level, this change does one thing. If either STIBP or IBPB
is set to conditional, allow the prctl to change the task flag.
Also, reflect that capability when querying the state. This isn't
perfect since it doesn't take into account if only STIBP or IBPB is
unconditionally on. But it allows the conditional feature to work as
expected, without affecting the unconditional one.
[ bp: Massage commit message and comment; space out statements for
better readability. ]
Fixes: 21998a351512 ("x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.")
Signed-off-by: Anand K Mistry <amistry@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lkml.kernel.org/r/20201105163246.v2.1.Ifd7243cd3e2c2206a893ad0a5b9a4f19549e22c6@changeid
2020-11-05 05:33:04 +00:00
x86/speculation: Add prctl() control for indirect branch speculation
Add the PR_SPEC_INDIRECT_BRANCH option for the PR_GET_SPECULATION_CTRL and
PR_SET_SPECULATION_CTRL prctls to allow fine grained per task control of
indirect branch speculation via STIBP and IBPB.
Invocations:
Check indirect branch speculation status with
- prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, 0, 0, 0);
Enable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE, 0, 0);
Disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE, 0, 0);
Force disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0);
See Documentation/userspace-api/spec_ctrl.rst.
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Casey Schaufler <casey.schaufler@intel.com>
Cc: Asit Mallick <asit.k.mallick@intel.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Jon Masters <jcm@redhat.com>
Cc: Waiman Long <longman9394@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Dave Stewart <david.c.stewart@intel.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20181125185005.866780996@linutronix.de
2018-11-25 18:33:53 +00:00
task_clear_spec_ib_disable ( task ) ;
task_update_spec_tif ( task ) ;
break ;
case PR_SPEC_DISABLE :
case PR_SPEC_FORCE_DISABLE :
/*
* Indirect branch speculation is always allowed when
* mitigation is force disabled .
*/
x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.
When STIBP is unavailable or enhanced IBRS is available, Linux
force-disables the IBPB mitigation of Spectre-BTB even when simultaneous
multithreading is disabled. While attempts to enable IBPB using
prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, ...) fail with
EPERM, the seccomp syscall (or its prctl(PR_SET_SECCOMP, ...) equivalent)
which are used e.g. by Chromium or OpenSSH succeed with no errors but the
application remains silently vulnerable to cross-process Spectre v2 attacks
(classical BTB poisoning). At the same time the SYSFS reporting
(/sys/devices/system/cpu/vulnerabilities/spectre_v2) displays that IBPB is
conditionally enabled when in fact it is unconditionally disabled.
STIBP is useful only when SMT is enabled. When SMT is disabled and STIBP is
unavailable, it makes no sense to force-disable also IBPB, because IBPB
protects against cross-process Spectre-BTB attacks regardless of the SMT
state. At the same time since missing STIBP was only observed on AMD CPUs,
AMD does not recommend using STIBP, but recommends using IBPB, so disabling
IBPB because of missing STIBP goes directly against AMD's advice:
https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf
Similarly, enhanced IBRS is designed to protect cross-core BTB poisoning
and BTB-poisoning attacks from user space against kernel (and
BTB-poisoning attacks from guest against hypervisor), it is not designed
to prevent cross-process (or cross-VM) BTB poisoning between processes (or
VMs) running on the same core. Therefore, even with enhanced IBRS it is
necessary to flush the BTB during context-switches, so there is no reason
to force disable IBPB when enhanced IBRS is available.
Enable the prctl control of IBPB even when STIBP is unavailable or enhanced
IBRS is available.
Fixes: 7cc765a67d8e ("x86/speculation: Enable prctl mode for spectre_v2_user")
Signed-off-by: Anthony Steinhauser <asteinhauser@google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
2020-05-19 13:40:42 +00:00
if ( spectre_v2_user_ibpb = = SPECTRE_V2_USER_NONE & &
spectre_v2_user_stibp = = SPECTRE_V2_USER_NONE )
x86/speculation: Add prctl() control for indirect branch speculation
Add the PR_SPEC_INDIRECT_BRANCH option for the PR_GET_SPECULATION_CTRL and
PR_SET_SPECULATION_CTRL prctls to allow fine grained per task control of
indirect branch speculation via STIBP and IBPB.
Invocations:
Check indirect branch speculation status with
- prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, 0, 0, 0);
Enable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE, 0, 0);
Disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE, 0, 0);
Force disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0);
See Documentation/userspace-api/spec_ctrl.rst.
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Casey Schaufler <casey.schaufler@intel.com>
Cc: Asit Mallick <asit.k.mallick@intel.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Jon Masters <jcm@redhat.com>
Cc: Waiman Long <longman9394@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Dave Stewart <david.c.stewart@intel.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20181125185005.866780996@linutronix.de
2018-11-25 18:33:53 +00:00
return - EPERM ;
x86/speculation: Allow IBPB to be conditionally enabled on CPUs with always-on STIBP
On AMD CPUs which have the feature X86_FEATURE_AMD_STIBP_ALWAYS_ON,
STIBP is set to on and
spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT_PREFERRED
At the same time, IBPB can be set to conditional.
However, this leads to the case where it's impossible to turn on IBPB
for a process because in the PR_SPEC_DISABLE case in ib_prctl_set() the
spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT_PREFERRED
condition leads to a return before the task flag is set. Similarly,
ib_prctl_get() will return PR_SPEC_DISABLE even though IBPB is set to
conditional.
More generally, the following cases are possible:
1. STIBP = conditional && IBPB = on for spectre_v2_user=seccomp,ibpb
2. STIBP = on && IBPB = conditional for AMD CPUs with
X86_FEATURE_AMD_STIBP_ALWAYS_ON
The first case functions correctly today, but only because
spectre_v2_user_ibpb isn't updated to reflect the IBPB mode.
At a high level, this change does one thing. If either STIBP or IBPB
is set to conditional, allow the prctl to change the task flag.
Also, reflect that capability when querying the state. This isn't
perfect since it doesn't take into account if only STIBP or IBPB is
unconditionally on. But it allows the conditional feature to work as
expected, without affecting the unconditional one.
[ bp: Massage commit message and comment; space out statements for
better readability. ]
Fixes: 21998a351512 ("x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.")
Signed-off-by: Anand K Mistry <amistry@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lkml.kernel.org/r/20201105163246.v2.1.Ifd7243cd3e2c2206a893ad0a5b9a4f19549e22c6@changeid
2020-11-05 05:33:04 +00:00
if ( ! is_spec_ib_user_controlled ( ) )
x86/speculation: Add prctl() control for indirect branch speculation
Add the PR_SPEC_INDIRECT_BRANCH option for the PR_GET_SPECULATION_CTRL and
PR_SET_SPECULATION_CTRL prctls to allow fine grained per task control of
indirect branch speculation via STIBP and IBPB.
Invocations:
Check indirect branch speculation status with
- prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, 0, 0, 0);
Enable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE, 0, 0);
Disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE, 0, 0);
Force disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0);
See Documentation/userspace-api/spec_ctrl.rst.
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Casey Schaufler <casey.schaufler@intel.com>
Cc: Asit Mallick <asit.k.mallick@intel.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Jon Masters <jcm@redhat.com>
Cc: Waiman Long <longman9394@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Dave Stewart <david.c.stewart@intel.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20181125185005.866780996@linutronix.de
2018-11-25 18:33:53 +00:00
return 0 ;
x86/speculation: Allow IBPB to be conditionally enabled on CPUs with always-on STIBP
On AMD CPUs which have the feature X86_FEATURE_AMD_STIBP_ALWAYS_ON,
STIBP is set to on and
spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT_PREFERRED
At the same time, IBPB can be set to conditional.
However, this leads to the case where it's impossible to turn on IBPB
for a process because in the PR_SPEC_DISABLE case in ib_prctl_set() the
spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT_PREFERRED
condition leads to a return before the task flag is set. Similarly,
ib_prctl_get() will return PR_SPEC_DISABLE even though IBPB is set to
conditional.
More generally, the following cases are possible:
1. STIBP = conditional && IBPB = on for spectre_v2_user=seccomp,ibpb
2. STIBP = on && IBPB = conditional for AMD CPUs with
X86_FEATURE_AMD_STIBP_ALWAYS_ON
The first case functions correctly today, but only because
spectre_v2_user_ibpb isn't updated to reflect the IBPB mode.
At a high level, this change does one thing. If either STIBP or IBPB
is set to conditional, allow the prctl to change the task flag.
Also, reflect that capability when querying the state. This isn't
perfect since it doesn't take into account if only STIBP or IBPB is
unconditionally on. But it allows the conditional feature to work as
expected, without affecting the unconditional one.
[ bp: Massage commit message and comment; space out statements for
better readability. ]
Fixes: 21998a351512 ("x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.")
Signed-off-by: Anand K Mistry <amistry@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lkml.kernel.org/r/20201105163246.v2.1.Ifd7243cd3e2c2206a893ad0a5b9a4f19549e22c6@changeid
2020-11-05 05:33:04 +00:00
x86/speculation: Add prctl() control for indirect branch speculation
Add the PR_SPEC_INDIRECT_BRANCH option for the PR_GET_SPECULATION_CTRL and
PR_SET_SPECULATION_CTRL prctls to allow fine grained per task control of
indirect branch speculation via STIBP and IBPB.
Invocations:
Check indirect branch speculation status with
- prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, 0, 0, 0);
Enable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE, 0, 0);
Disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE, 0, 0);
Force disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0);
See Documentation/userspace-api/spec_ctrl.rst.
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Casey Schaufler <casey.schaufler@intel.com>
Cc: Asit Mallick <asit.k.mallick@intel.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Jon Masters <jcm@redhat.com>
Cc: Waiman Long <longman9394@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Dave Stewart <david.c.stewart@intel.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20181125185005.866780996@linutronix.de
2018-11-25 18:33:53 +00:00
task_set_spec_ib_disable ( task ) ;
if ( ctrl = = PR_SPEC_FORCE_DISABLE )
task_set_spec_ib_force_disable ( task ) ;
task_update_spec_tif ( task ) ;
2023-01-03 20:17:51 +00:00
if ( task = = current )
indirect_branch_prediction_barrier ( ) ;
x86/speculation: Add prctl() control for indirect branch speculation
Add the PR_SPEC_INDIRECT_BRANCH option for the PR_GET_SPECULATION_CTRL and
PR_SET_SPECULATION_CTRL prctls to allow fine grained per task control of
indirect branch speculation via STIBP and IBPB.
Invocations:
Check indirect branch speculation status with
- prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, 0, 0, 0);
Enable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE, 0, 0);
Disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE, 0, 0);
Force disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0);
See Documentation/userspace-api/spec_ctrl.rst.
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Casey Schaufler <casey.schaufler@intel.com>
Cc: Asit Mallick <asit.k.mallick@intel.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Jon Masters <jcm@redhat.com>
Cc: Waiman Long <longman9394@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Dave Stewart <david.c.stewart@intel.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20181125185005.866780996@linutronix.de
2018-11-25 18:33:53 +00:00
break ;
default :
return - ERANGE ;
}
return 0 ;
}
2018-05-04 13:12:06 +00:00
int arch_prctl_spec_ctrl_set ( struct task_struct * task , unsigned long which ,
unsigned long ctrl )
{
switch ( which ) {
case PR_SPEC_STORE_BYPASS :
return ssb_prctl_set ( task , ctrl ) ;
x86/speculation: Add prctl() control for indirect branch speculation
Add the PR_SPEC_INDIRECT_BRANCH option for the PR_GET_SPECULATION_CTRL and
PR_SET_SPECULATION_CTRL prctls to allow fine grained per task control of
indirect branch speculation via STIBP and IBPB.
Invocations:
Check indirect branch speculation status with
- prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, 0, 0, 0);
Enable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE, 0, 0);
Disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE, 0, 0);
Force disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0);
See Documentation/userspace-api/spec_ctrl.rst.
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Casey Schaufler <casey.schaufler@intel.com>
Cc: Asit Mallick <asit.k.mallick@intel.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Jon Masters <jcm@redhat.com>
Cc: Waiman Long <longman9394@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Dave Stewart <david.c.stewart@intel.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20181125185005.866780996@linutronix.de
2018-11-25 18:33:53 +00:00
case PR_SPEC_INDIRECT_BRANCH :
return ib_prctl_set ( task , ctrl ) ;
2021-01-08 12:10:55 +00:00
case PR_SPEC_L1D_FLUSH :
return l1d_flush_prctl_set ( task , ctrl ) ;
2018-05-04 13:12:06 +00:00
default :
return - ENODEV ;
}
}
# ifdef CONFIG_SECCOMP
void arch_seccomp_spec_mitigate ( struct task_struct * task )
{
2018-05-03 21:37:54 +00:00
if ( ssb_mode = = SPEC_STORE_BYPASS_SECCOMP )
ssb_prctl_set ( task , PR_SPEC_FORCE_DISABLE ) ;
x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.
When STIBP is unavailable or enhanced IBRS is available, Linux
force-disables the IBPB mitigation of Spectre-BTB even when simultaneous
multithreading is disabled. While attempts to enable IBPB using
prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, ...) fail with
EPERM, the seccomp syscall (or its prctl(PR_SET_SECCOMP, ...) equivalent)
which are used e.g. by Chromium or OpenSSH succeed with no errors but the
application remains silently vulnerable to cross-process Spectre v2 attacks
(classical BTB poisoning). At the same time the SYSFS reporting
(/sys/devices/system/cpu/vulnerabilities/spectre_v2) displays that IBPB is
conditionally enabled when in fact it is unconditionally disabled.
STIBP is useful only when SMT is enabled. When SMT is disabled and STIBP is
unavailable, it makes no sense to force-disable also IBPB, because IBPB
protects against cross-process Spectre-BTB attacks regardless of the SMT
state. At the same time since missing STIBP was only observed on AMD CPUs,
AMD does not recommend using STIBP, but recommends using IBPB, so disabling
IBPB because of missing STIBP goes directly against AMD's advice:
https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf
Similarly, enhanced IBRS is designed to protect cross-core BTB poisoning
and BTB-poisoning attacks from user space against kernel (and
BTB-poisoning attacks from guest against hypervisor), it is not designed
to prevent cross-process (or cross-VM) BTB poisoning between processes (or
VMs) running on the same core. Therefore, even with enhanced IBRS it is
necessary to flush the BTB during context-switches, so there is no reason
to force disable IBPB when enhanced IBRS is available.
Enable the prctl control of IBPB even when STIBP is unavailable or enhanced
IBRS is available.
Fixes: 7cc765a67d8e ("x86/speculation: Enable prctl mode for spectre_v2_user")
Signed-off-by: Anthony Steinhauser <asteinhauser@google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
2020-05-19 13:40:42 +00:00
if ( spectre_v2_user_ibpb = = SPECTRE_V2_USER_SECCOMP | |
spectre_v2_user_stibp = = SPECTRE_V2_USER_SECCOMP )
2018-11-25 18:33:55 +00:00
ib_prctl_set ( task , PR_SPEC_FORCE_DISABLE ) ;
2018-05-04 13:12:06 +00:00
}
# endif
2021-01-08 12:10:55 +00:00
static int l1d_flush_prctl_get ( struct task_struct * task )
{
if ( ! static_branch_unlikely ( & switch_mm_cond_l1d_flush ) )
return PR_SPEC_FORCE_DISABLE ;
if ( test_ti_thread_flag ( & task - > thread_info , TIF_SPEC_L1D_FLUSH ) )
return PR_SPEC_PRCTL | PR_SPEC_ENABLE ;
else
return PR_SPEC_PRCTL | PR_SPEC_DISABLE ;
}
2018-05-01 22:19:04 +00:00
static int ssb_prctl_get ( struct task_struct * task )
2018-04-29 13:26:40 +00:00
{
switch ( ssb_mode ) {
case SPEC_STORE_BYPASS_DISABLE :
return PR_SPEC_DISABLE ;
2018-05-03 21:37:54 +00:00
case SPEC_STORE_BYPASS_SECCOMP :
2018-04-29 13:26:40 +00:00
case SPEC_STORE_BYPASS_PRCTL :
2018-05-03 20:09:15 +00:00
if ( task_spec_ssb_force_disable ( task ) )
return PR_SPEC_PRCTL | PR_SPEC_FORCE_DISABLE ;
2019-01-16 22:01:36 +00:00
if ( task_spec_ssb_noexec ( task ) )
return PR_SPEC_PRCTL | PR_SPEC_DISABLE_NOEXEC ;
2018-05-03 20:09:15 +00:00
if ( task_spec_ssb_disable ( task ) )
2018-04-29 13:26:40 +00:00
return PR_SPEC_PRCTL | PR_SPEC_DISABLE ;
return PR_SPEC_PRCTL | PR_SPEC_ENABLE ;
default :
if ( boot_cpu_has_bug ( X86_BUG_SPEC_STORE_BYPASS ) )
return PR_SPEC_ENABLE ;
return PR_SPEC_NOT_AFFECTED ;
}
}
x86/speculation: Add prctl() control for indirect branch speculation
Add the PR_SPEC_INDIRECT_BRANCH option for the PR_GET_SPECULATION_CTRL and
PR_SET_SPECULATION_CTRL prctls to allow fine grained per task control of
indirect branch speculation via STIBP and IBPB.
Invocations:
Check indirect branch speculation status with
- prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, 0, 0, 0);
Enable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE, 0, 0);
Disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE, 0, 0);
Force disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0);
See Documentation/userspace-api/spec_ctrl.rst.
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Casey Schaufler <casey.schaufler@intel.com>
Cc: Asit Mallick <asit.k.mallick@intel.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Jon Masters <jcm@redhat.com>
Cc: Waiman Long <longman9394@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Dave Stewart <david.c.stewart@intel.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20181125185005.866780996@linutronix.de
2018-11-25 18:33:53 +00:00
static int ib_prctl_get ( struct task_struct * task )
{
if ( ! boot_cpu_has_bug ( X86_BUG_SPECTRE_V2 ) )
return PR_SPEC_NOT_AFFECTED ;
x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.
When STIBP is unavailable or enhanced IBRS is available, Linux
force-disables the IBPB mitigation of Spectre-BTB even when simultaneous
multithreading is disabled. While attempts to enable IBPB using
prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, ...) fail with
EPERM, the seccomp syscall (or its prctl(PR_SET_SECCOMP, ...) equivalent)
which are used e.g. by Chromium or OpenSSH succeed with no errors but the
application remains silently vulnerable to cross-process Spectre v2 attacks
(classical BTB poisoning). At the same time the SYSFS reporting
(/sys/devices/system/cpu/vulnerabilities/spectre_v2) displays that IBPB is
conditionally enabled when in fact it is unconditionally disabled.
STIBP is useful only when SMT is enabled. When SMT is disabled and STIBP is
unavailable, it makes no sense to force-disable also IBPB, because IBPB
protects against cross-process Spectre-BTB attacks regardless of the SMT
state. At the same time since missing STIBP was only observed on AMD CPUs,
AMD does not recommend using STIBP, but recommends using IBPB, so disabling
IBPB because of missing STIBP goes directly against AMD's advice:
https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf
Similarly, enhanced IBRS is designed to protect cross-core BTB poisoning
and BTB-poisoning attacks from user space against kernel (and
BTB-poisoning attacks from guest against hypervisor), it is not designed
to prevent cross-process (or cross-VM) BTB poisoning between processes (or
VMs) running on the same core. Therefore, even with enhanced IBRS it is
necessary to flush the BTB during context-switches, so there is no reason
to force disable IBPB when enhanced IBRS is available.
Enable the prctl control of IBPB even when STIBP is unavailable or enhanced
IBRS is available.
Fixes: 7cc765a67d8e ("x86/speculation: Enable prctl mode for spectre_v2_user")
Signed-off-by: Anthony Steinhauser <asteinhauser@google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
2020-05-19 13:40:42 +00:00
if ( spectre_v2_user_ibpb = = SPECTRE_V2_USER_NONE & &
spectre_v2_user_stibp = = SPECTRE_V2_USER_NONE )
x86/speculation: Add prctl() control for indirect branch speculation
Add the PR_SPEC_INDIRECT_BRANCH option for the PR_GET_SPECULATION_CTRL and
PR_SET_SPECULATION_CTRL prctls to allow fine grained per task control of
indirect branch speculation via STIBP and IBPB.
Invocations:
Check indirect branch speculation status with
- prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, 0, 0, 0);
Enable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE, 0, 0);
Disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE, 0, 0);
Force disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0);
See Documentation/userspace-api/spec_ctrl.rst.
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Casey Schaufler <casey.schaufler@intel.com>
Cc: Asit Mallick <asit.k.mallick@intel.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Jon Masters <jcm@redhat.com>
Cc: Waiman Long <longman9394@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Dave Stewart <david.c.stewart@intel.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20181125185005.866780996@linutronix.de
2018-11-25 18:33:53 +00:00
return PR_SPEC_ENABLE ;
x86/speculation: Allow IBPB to be conditionally enabled on CPUs with always-on STIBP
On AMD CPUs which have the feature X86_FEATURE_AMD_STIBP_ALWAYS_ON,
STIBP is set to on and
spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT_PREFERRED
At the same time, IBPB can be set to conditional.
However, this leads to the case where it's impossible to turn on IBPB
for a process because in the PR_SPEC_DISABLE case in ib_prctl_set() the
spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT_PREFERRED
condition leads to a return before the task flag is set. Similarly,
ib_prctl_get() will return PR_SPEC_DISABLE even though IBPB is set to
conditional.
More generally, the following cases are possible:
1. STIBP = conditional && IBPB = on for spectre_v2_user=seccomp,ibpb
2. STIBP = on && IBPB = conditional for AMD CPUs with
X86_FEATURE_AMD_STIBP_ALWAYS_ON
The first case functions correctly today, but only because
spectre_v2_user_ibpb isn't updated to reflect the IBPB mode.
At a high level, this change does one thing. If either STIBP or IBPB
is set to conditional, allow the prctl to change the task flag.
Also, reflect that capability when querying the state. This isn't
perfect since it doesn't take into account if only STIBP or IBPB is
unconditionally on. But it allows the conditional feature to work as
expected, without affecting the unconditional one.
[ bp: Massage commit message and comment; space out statements for
better readability. ]
Fixes: 21998a351512 ("x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.")
Signed-off-by: Anand K Mistry <amistry@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lkml.kernel.org/r/20201105163246.v2.1.Ifd7243cd3e2c2206a893ad0a5b9a4f19549e22c6@changeid
2020-11-05 05:33:04 +00:00
else if ( is_spec_ib_user_controlled ( ) ) {
x86/speculation: Add prctl() control for indirect branch speculation
Add the PR_SPEC_INDIRECT_BRANCH option for the PR_GET_SPECULATION_CTRL and
PR_SET_SPECULATION_CTRL prctls to allow fine grained per task control of
indirect branch speculation via STIBP and IBPB.
Invocations:
Check indirect branch speculation status with
- prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, 0, 0, 0);
Enable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE, 0, 0);
Disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE, 0, 0);
Force disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0);
See Documentation/userspace-api/spec_ctrl.rst.
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Casey Schaufler <casey.schaufler@intel.com>
Cc: Asit Mallick <asit.k.mallick@intel.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Jon Masters <jcm@redhat.com>
Cc: Waiman Long <longman9394@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Dave Stewart <david.c.stewart@intel.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20181125185005.866780996@linutronix.de
2018-11-25 18:33:53 +00:00
if ( task_spec_ib_force_disable ( task ) )
return PR_SPEC_PRCTL | PR_SPEC_FORCE_DISABLE ;
if ( task_spec_ib_disable ( task ) )
return PR_SPEC_PRCTL | PR_SPEC_DISABLE ;
return PR_SPEC_PRCTL | PR_SPEC_ENABLE ;
x86/speculation: Allow IBPB to be conditionally enabled on CPUs with always-on STIBP
On AMD CPUs which have the feature X86_FEATURE_AMD_STIBP_ALWAYS_ON,
STIBP is set to on and
spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT_PREFERRED
At the same time, IBPB can be set to conditional.
However, this leads to the case where it's impossible to turn on IBPB
for a process because in the PR_SPEC_DISABLE case in ib_prctl_set() the
spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT_PREFERRED
condition leads to a return before the task flag is set. Similarly,
ib_prctl_get() will return PR_SPEC_DISABLE even though IBPB is set to
conditional.
More generally, the following cases are possible:
1. STIBP = conditional && IBPB = on for spectre_v2_user=seccomp,ibpb
2. STIBP = on && IBPB = conditional for AMD CPUs with
X86_FEATURE_AMD_STIBP_ALWAYS_ON
The first case functions correctly today, but only because
spectre_v2_user_ibpb isn't updated to reflect the IBPB mode.
At a high level, this change does one thing. If either STIBP or IBPB
is set to conditional, allow the prctl to change the task flag.
Also, reflect that capability when querying the state. This isn't
perfect since it doesn't take into account if only STIBP or IBPB is
unconditionally on. But it allows the conditional feature to work as
expected, without affecting the unconditional one.
[ bp: Massage commit message and comment; space out statements for
better readability. ]
Fixes: 21998a351512 ("x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.")
Signed-off-by: Anand K Mistry <amistry@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lkml.kernel.org/r/20201105163246.v2.1.Ifd7243cd3e2c2206a893ad0a5b9a4f19549e22c6@changeid
2020-11-05 05:33:04 +00:00
} else if ( spectre_v2_user_ibpb = = SPECTRE_V2_USER_STRICT | |
spectre_v2_user_stibp = = SPECTRE_V2_USER_STRICT | |
spectre_v2_user_stibp = = SPECTRE_V2_USER_STRICT_PREFERRED )
return PR_SPEC_DISABLE ;
else
x86/speculation: Add prctl() control for indirect branch speculation
Add the PR_SPEC_INDIRECT_BRANCH option for the PR_GET_SPECULATION_CTRL and
PR_SET_SPECULATION_CTRL prctls to allow fine grained per task control of
indirect branch speculation via STIBP and IBPB.
Invocations:
Check indirect branch speculation status with
- prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, 0, 0, 0);
Enable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE, 0, 0);
Disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE, 0, 0);
Force disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0);
See Documentation/userspace-api/spec_ctrl.rst.
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Casey Schaufler <casey.schaufler@intel.com>
Cc: Asit Mallick <asit.k.mallick@intel.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Jon Masters <jcm@redhat.com>
Cc: Waiman Long <longman9394@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Dave Stewart <david.c.stewart@intel.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20181125185005.866780996@linutronix.de
2018-11-25 18:33:53 +00:00
return PR_SPEC_NOT_AFFECTED ;
}
2018-05-01 22:19:04 +00:00
int arch_prctl_spec_ctrl_get ( struct task_struct * task , unsigned long which )
2018-04-29 13:26:40 +00:00
{
switch ( which ) {
case PR_SPEC_STORE_BYPASS :
2018-05-01 22:19:04 +00:00
return ssb_prctl_get ( task ) ;
x86/speculation: Add prctl() control for indirect branch speculation
Add the PR_SPEC_INDIRECT_BRANCH option for the PR_GET_SPECULATION_CTRL and
PR_SET_SPECULATION_CTRL prctls to allow fine grained per task control of
indirect branch speculation via STIBP and IBPB.
Invocations:
Check indirect branch speculation status with
- prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, 0, 0, 0);
Enable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE, 0, 0);
Disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE, 0, 0);
Force disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0);
See Documentation/userspace-api/spec_ctrl.rst.
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Casey Schaufler <casey.schaufler@intel.com>
Cc: Asit Mallick <asit.k.mallick@intel.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Jon Masters <jcm@redhat.com>
Cc: Waiman Long <longman9394@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Dave Stewart <david.c.stewart@intel.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20181125185005.866780996@linutronix.de
2018-11-25 18:33:53 +00:00
case PR_SPEC_INDIRECT_BRANCH :
return ib_prctl_get ( task ) ;
2021-01-08 12:10:55 +00:00
case PR_SPEC_L1D_FLUSH :
return l1d_flush_prctl_get ( task ) ;
2018-04-29 13:26:40 +00:00
default :
return - ENODEV ;
}
}
2018-04-26 02:04:22 +00:00
void x86_spec_ctrl_setup_ap ( void )
{
2018-05-10 17:13:18 +00:00
if ( boot_cpu_has ( X86_FEATURE_MSR_SPEC_CTRL ) )
2022-11-30 15:25:51 +00:00
update_spec_ctrl ( x86_spec_ctrl_base ) ;
2018-04-26 02:04:24 +00:00
if ( ssb_mode = = SPEC_STORE_BYPASS_DISABLE )
2018-05-09 19:41:38 +00:00
x86_amd_ssb_disable ( ) ;
2018-04-26 02:04:22 +00:00
}
2019-11-04 11:22:02 +00:00
bool itlb_multihit_kvm_mitigation ;
EXPORT_SYMBOL_GPL ( itlb_multihit_kvm_mitigation ) ;
2018-06-20 20:42:57 +00:00
# undef pr_fmt
# define pr_fmt(fmt) "L1TF: " fmt
2018-07-13 14:23:16 +00:00
x86/bugs, kvm: Introduce boot-time control of L1TF mitigations
Introduce the 'l1tf=' kernel command line option to allow for boot-time
switching of mitigation that is used on processors affected by L1TF.
The possible values are:
full
Provides all available mitigations for the L1TF vulnerability. Disables
SMT and enables all mitigations in the hypervisors. SMT control via
/sys/devices/system/cpu/smt/control is still possible after boot.
Hypervisors will issue a warning when the first VM is started in
a potentially insecure configuration, i.e. SMT enabled or L1D flush
disabled.
full,force
Same as 'full', but disables SMT control. Implies the 'nosmt=force'
command line option. sysfs control of SMT and the hypervisor flush
control is disabled.
flush
Leaves SMT enabled and enables the conditional hypervisor mitigation.
Hypervisors will issue a warning when the first VM is started in a
potentially insecure configuration, i.e. SMT enabled or L1D flush
disabled.
flush,nosmt
Disables SMT and enables the conditional hypervisor mitigation. SMT
control via /sys/devices/system/cpu/smt/control is still possible
after boot. If SMT is reenabled or flushing disabled at runtime
hypervisors will issue a warning.
flush,nowarn
Same as 'flush', but hypervisors will not warn when
a VM is started in a potentially insecure configuration.
off
Disables hypervisor mitigations and doesn't emit any warnings.
Default is 'flush'.
Let KVM adhere to these semantics, which means:
- 'lt1f=full,force' : Performe L1D flushes. No runtime control
possible.
- 'l1tf=full'
- 'l1tf-flush'
- 'l1tf=flush,nosmt' : Perform L1D flushes and warn on VM start if
SMT has been runtime enabled or L1D flushing
has been run-time enabled
- 'l1tf=flush,nowarn' : Perform L1D flushes and no warnings are emitted.
- 'l1tf=off' : L1D flushes are not performed and no warnings
are emitted.
KVM can always override the L1D flushing behavior using its 'vmentry_l1d_flush'
module parameter except when lt1f=full,force is set.
This makes KVM's private 'nosmt' option redundant, and as it is a bit
non-systematic anyway (this is something to control globally, not on
hypervisor level), remove that option.
Add the missing Documentation entry for the l1tf vulnerability sysfs file
while at it.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Jiri Kosina <jkosina@suse.cz>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
Link: https://lkml.kernel.org/r/20180713142323.202758176@linutronix.de
2018-07-13 14:23:25 +00:00
/* Default mitigation for L1TF-affected CPUs */
enum l1tf_mitigations l1tf_mitigation __ro_after_init = L1TF_MITIGATION_FLUSH ;
2018-07-13 14:23:16 +00:00
# if IS_ENABLED(CONFIG_KVM_INTEL)
x86/bugs, kvm: Introduce boot-time control of L1TF mitigations
Introduce the 'l1tf=' kernel command line option to allow for boot-time
switching of mitigation that is used on processors affected by L1TF.
The possible values are:
full
Provides all available mitigations for the L1TF vulnerability. Disables
SMT and enables all mitigations in the hypervisors. SMT control via
/sys/devices/system/cpu/smt/control is still possible after boot.
Hypervisors will issue a warning when the first VM is started in
a potentially insecure configuration, i.e. SMT enabled or L1D flush
disabled.
full,force
Same as 'full', but disables SMT control. Implies the 'nosmt=force'
command line option. sysfs control of SMT and the hypervisor flush
control is disabled.
flush
Leaves SMT enabled and enables the conditional hypervisor mitigation.
Hypervisors will issue a warning when the first VM is started in a
potentially insecure configuration, i.e. SMT enabled or L1D flush
disabled.
flush,nosmt
Disables SMT and enables the conditional hypervisor mitigation. SMT
control via /sys/devices/system/cpu/smt/control is still possible
after boot. If SMT is reenabled or flushing disabled at runtime
hypervisors will issue a warning.
flush,nowarn
Same as 'flush', but hypervisors will not warn when
a VM is started in a potentially insecure configuration.
off
Disables hypervisor mitigations and doesn't emit any warnings.
Default is 'flush'.
Let KVM adhere to these semantics, which means:
- 'lt1f=full,force' : Performe L1D flushes. No runtime control
possible.
- 'l1tf=full'
- 'l1tf-flush'
- 'l1tf=flush,nosmt' : Perform L1D flushes and warn on VM start if
SMT has been runtime enabled or L1D flushing
has been run-time enabled
- 'l1tf=flush,nowarn' : Perform L1D flushes and no warnings are emitted.
- 'l1tf=off' : L1D flushes are not performed and no warnings
are emitted.
KVM can always override the L1D flushing behavior using its 'vmentry_l1d_flush'
module parameter except when lt1f=full,force is set.
This makes KVM's private 'nosmt' option redundant, and as it is a bit
non-systematic anyway (this is something to control globally, not on
hypervisor level), remove that option.
Add the missing Documentation entry for the l1tf vulnerability sysfs file
while at it.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Jiri Kosina <jkosina@suse.cz>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
Link: https://lkml.kernel.org/r/20180713142323.202758176@linutronix.de
2018-07-13 14:23:25 +00:00
EXPORT_SYMBOL_GPL ( l1tf_mitigation ) ;
2018-08-15 15:38:33 +00:00
# endif
2018-07-13 14:23:22 +00:00
enum vmx_l1d_flush_state l1tf_vmx_mitigation = VMENTER_L1D_FLUSH_AUTO ;
2018-07-13 14:23:16 +00:00
EXPORT_SYMBOL_GPL ( l1tf_vmx_mitigation ) ;
2018-08-24 17:03:50 +00:00
/*
* These CPUs all support 44 bits physical address space internally in the
* cache but CPUID can report a smaller number of physical address bits .
*
* The L1TF mitigation uses the top most address bit for the inversion of
* non present PTEs . When the installed memory reaches into the top most
* address bit due to memory holes , which has been observed on machines
* which report 36 bits physical address bits and have 32 G RAM installed ,
* then the mitigation range check in l1tf_select_mitigation ( ) triggers .
* This is a false positive because the mitigation is still possible due to
* the fact that the cache uses 44 bit internally . Use the cache bits
* instead of the reported physical bits and adjust them on the affected
* machines to 44 bit if the reported bits are less than 44.
*/
static void override_cache_bits ( struct cpuinfo_x86 * c )
{
if ( c - > x86 ! = 6 )
return ;
switch ( c - > x86_model ) {
case INTEL_FAM6_NEHALEM :
case INTEL_FAM6_WESTMERE :
case INTEL_FAM6_SANDYBRIDGE :
case INTEL_FAM6_IVYBRIDGE :
2019-08-27 19:48:21 +00:00
case INTEL_FAM6_HASWELL :
2019-08-27 19:48:22 +00:00
case INTEL_FAM6_HASWELL_L :
2019-08-27 19:48:23 +00:00
case INTEL_FAM6_HASWELL_G :
2019-08-27 19:48:21 +00:00
case INTEL_FAM6_BROADWELL :
2019-08-27 19:48:23 +00:00
case INTEL_FAM6_BROADWELL_G :
2019-08-27 19:48:22 +00:00
case INTEL_FAM6_SKYLAKE_L :
2019-08-27 19:48:21 +00:00
case INTEL_FAM6_SKYLAKE :
2019-08-27 19:48:22 +00:00
case INTEL_FAM6_KABYLAKE_L :
2019-08-27 19:48:21 +00:00
case INTEL_FAM6_KABYLAKE :
2018-08-24 17:03:50 +00:00
if ( c - > x86_cache_bits < 44 )
c - > x86_cache_bits = 44 ;
break ;
}
}
2018-06-20 20:42:57 +00:00
static void __init l1tf_select_mitigation ( void )
{
u64 half_pa ;
if ( ! boot_cpu_has_bug ( X86_BUG_L1TF ) )
return ;
2019-04-12 20:39:29 +00:00
if ( cpu_mitigations_off ( ) )
l1tf_mitigation = L1TF_MITIGATION_OFF ;
else if ( cpu_mitigations_auto_nosmt ( ) )
l1tf_mitigation = L1TF_MITIGATION_FLUSH_NOSMT ;
2018-08-24 17:03:50 +00:00
override_cache_bits ( & boot_cpu_data ) ;
x86/bugs, kvm: Introduce boot-time control of L1TF mitigations
Introduce the 'l1tf=' kernel command line option to allow for boot-time
switching of mitigation that is used on processors affected by L1TF.
The possible values are:
full
Provides all available mitigations for the L1TF vulnerability. Disables
SMT and enables all mitigations in the hypervisors. SMT control via
/sys/devices/system/cpu/smt/control is still possible after boot.
Hypervisors will issue a warning when the first VM is started in
a potentially insecure configuration, i.e. SMT enabled or L1D flush
disabled.
full,force
Same as 'full', but disables SMT control. Implies the 'nosmt=force'
command line option. sysfs control of SMT and the hypervisor flush
control is disabled.
flush
Leaves SMT enabled and enables the conditional hypervisor mitigation.
Hypervisors will issue a warning when the first VM is started in a
potentially insecure configuration, i.e. SMT enabled or L1D flush
disabled.
flush,nosmt
Disables SMT and enables the conditional hypervisor mitigation. SMT
control via /sys/devices/system/cpu/smt/control is still possible
after boot. If SMT is reenabled or flushing disabled at runtime
hypervisors will issue a warning.
flush,nowarn
Same as 'flush', but hypervisors will not warn when
a VM is started in a potentially insecure configuration.
off
Disables hypervisor mitigations and doesn't emit any warnings.
Default is 'flush'.
Let KVM adhere to these semantics, which means:
- 'lt1f=full,force' : Performe L1D flushes. No runtime control
possible.
- 'l1tf=full'
- 'l1tf-flush'
- 'l1tf=flush,nosmt' : Perform L1D flushes and warn on VM start if
SMT has been runtime enabled or L1D flushing
has been run-time enabled
- 'l1tf=flush,nowarn' : Perform L1D flushes and no warnings are emitted.
- 'l1tf=off' : L1D flushes are not performed and no warnings
are emitted.
KVM can always override the L1D flushing behavior using its 'vmentry_l1d_flush'
module parameter except when lt1f=full,force is set.
This makes KVM's private 'nosmt' option redundant, and as it is a bit
non-systematic anyway (this is something to control globally, not on
hypervisor level), remove that option.
Add the missing Documentation entry for the l1tf vulnerability sysfs file
while at it.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Jiri Kosina <jkosina@suse.cz>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
Link: https://lkml.kernel.org/r/20180713142323.202758176@linutronix.de
2018-07-13 14:23:25 +00:00
switch ( l1tf_mitigation ) {
case L1TF_MITIGATION_OFF :
case L1TF_MITIGATION_FLUSH_NOWARN :
case L1TF_MITIGATION_FLUSH :
break ;
case L1TF_MITIGATION_FLUSH_NOSMT :
case L1TF_MITIGATION_FULL :
cpu_smt_disable ( false ) ;
break ;
case L1TF_MITIGATION_FULL_FORCE :
cpu_smt_disable ( true ) ;
break ;
}
2018-06-20 20:42:57 +00:00
# if CONFIG_PGTABLE_LEVELS == 2
pr_warn ( " Kernel not compiled for PAE. No mitigation for L1TF \n " ) ;
return ;
# endif
half_pa = ( u64 ) l1tf_pfn_limit ( ) < < PAGE_SHIFT ;
2018-11-13 18:49:10 +00:00
if ( l1tf_mitigation ! = L1TF_MITIGATION_OFF & &
e820__mapped_any ( half_pa , ULLONG_MAX - half_pa , E820_TYPE_RAM ) ) {
2018-06-20 20:42:57 +00:00
pr_warn ( " System has more than MAX_PA/2 memory. L1TF mitigation not effective. \n " ) ;
2018-08-23 14:21:29 +00:00
pr_info ( " You may make it effective by booting the kernel with mem=%llu parameter. \n " ,
half_pa ) ;
pr_info ( " However, doing so will make a part of your RAM unusable. \n " ) ;
2019-02-19 10:10:49 +00:00
pr_info ( " Reading https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html might help you decide. \n " ) ;
2018-06-20 20:42:57 +00:00
return ;
}
setup_force_cpu_cap ( X86_FEATURE_L1TF_PTEINV ) ;
}
x86/bugs, kvm: Introduce boot-time control of L1TF mitigations
Introduce the 'l1tf=' kernel command line option to allow for boot-time
switching of mitigation that is used on processors affected by L1TF.
The possible values are:
full
Provides all available mitigations for the L1TF vulnerability. Disables
SMT and enables all mitigations in the hypervisors. SMT control via
/sys/devices/system/cpu/smt/control is still possible after boot.
Hypervisors will issue a warning when the first VM is started in
a potentially insecure configuration, i.e. SMT enabled or L1D flush
disabled.
full,force
Same as 'full', but disables SMT control. Implies the 'nosmt=force'
command line option. sysfs control of SMT and the hypervisor flush
control is disabled.
flush
Leaves SMT enabled and enables the conditional hypervisor mitigation.
Hypervisors will issue a warning when the first VM is started in a
potentially insecure configuration, i.e. SMT enabled or L1D flush
disabled.
flush,nosmt
Disables SMT and enables the conditional hypervisor mitigation. SMT
control via /sys/devices/system/cpu/smt/control is still possible
after boot. If SMT is reenabled or flushing disabled at runtime
hypervisors will issue a warning.
flush,nowarn
Same as 'flush', but hypervisors will not warn when
a VM is started in a potentially insecure configuration.
off
Disables hypervisor mitigations and doesn't emit any warnings.
Default is 'flush'.
Let KVM adhere to these semantics, which means:
- 'lt1f=full,force' : Performe L1D flushes. No runtime control
possible.
- 'l1tf=full'
- 'l1tf-flush'
- 'l1tf=flush,nosmt' : Perform L1D flushes and warn on VM start if
SMT has been runtime enabled or L1D flushing
has been run-time enabled
- 'l1tf=flush,nowarn' : Perform L1D flushes and no warnings are emitted.
- 'l1tf=off' : L1D flushes are not performed and no warnings
are emitted.
KVM can always override the L1D flushing behavior using its 'vmentry_l1d_flush'
module parameter except when lt1f=full,force is set.
This makes KVM's private 'nosmt' option redundant, and as it is a bit
non-systematic anyway (this is something to control globally, not on
hypervisor level), remove that option.
Add the missing Documentation entry for the l1tf vulnerability sysfs file
while at it.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Jiri Kosina <jkosina@suse.cz>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
Link: https://lkml.kernel.org/r/20180713142323.202758176@linutronix.de
2018-07-13 14:23:25 +00:00
static int __init l1tf_cmdline ( char * str )
{
if ( ! boot_cpu_has_bug ( X86_BUG_L1TF ) )
return 0 ;
if ( ! str )
return - EINVAL ;
if ( ! strcmp ( str , " off " ) )
l1tf_mitigation = L1TF_MITIGATION_OFF ;
else if ( ! strcmp ( str , " flush,nowarn " ) )
l1tf_mitigation = L1TF_MITIGATION_FLUSH_NOWARN ;
else if ( ! strcmp ( str , " flush " ) )
l1tf_mitigation = L1TF_MITIGATION_FLUSH ;
else if ( ! strcmp ( str , " flush,nosmt " ) )
l1tf_mitigation = L1TF_MITIGATION_FLUSH_NOSMT ;
else if ( ! strcmp ( str , " full " ) )
l1tf_mitigation = L1TF_MITIGATION_FULL ;
else if ( ! strcmp ( str , " full,force " ) )
l1tf_mitigation = L1TF_MITIGATION_FULL_FORCE ;
return 0 ;
}
early_param ( " l1tf " , l1tf_cmdline ) ;
2018-06-20 20:42:57 +00:00
# undef pr_fmt
2019-04-02 15:00:51 +00:00
# define pr_fmt(fmt) fmt
2018-06-20 20:42:57 +00:00
2018-01-07 21:48:01 +00:00
# ifdef CONFIG_SYSFS
2018-04-26 02:04:17 +00:00
2018-07-13 14:23:16 +00:00
# define L1TF_DEFAULT_MSG "Mitigation: PTE Inversion"
# if IS_ENABLED(CONFIG_KVM_INTEL)
2018-11-25 18:33:42 +00:00
static const char * const l1tf_vmx_states [ ] = {
2018-07-13 14:23:18 +00:00
[ VMENTER_L1D_FLUSH_AUTO ] = " auto " ,
[ VMENTER_L1D_FLUSH_NEVER ] = " vulnerable " ,
[ VMENTER_L1D_FLUSH_COND ] = " conditional cache flushes " ,
[ VMENTER_L1D_FLUSH_ALWAYS ] = " cache flushes " ,
[ VMENTER_L1D_FLUSH_EPT_DISABLED ] = " EPT disabled " ,
2018-08-05 14:07:46 +00:00
[ VMENTER_L1D_FLUSH_NOT_REQUIRED ] = " flush not necessary "
2018-07-13 14:23:16 +00:00
} ;
static ssize_t l1tf_show_state ( char * buf )
{
if ( l1tf_vmx_mitigation = = VMENTER_L1D_FLUSH_AUTO )
2022-08-09 15:32:02 +00:00
return sysfs_emit ( buf , " %s \n " , L1TF_DEFAULT_MSG ) ;
2018-07-13 14:23:16 +00:00
2018-08-05 14:07:45 +00:00
if ( l1tf_vmx_mitigation = = VMENTER_L1D_FLUSH_EPT_DISABLED | |
( l1tf_vmx_mitigation = = VMENTER_L1D_FLUSH_NEVER & &
2018-11-25 18:33:40 +00:00
sched_smt_active ( ) ) ) {
2022-08-09 15:32:02 +00:00
return sysfs_emit ( buf , " %s; VMX: %s \n " , L1TF_DEFAULT_MSG ,
l1tf_vmx_states [ l1tf_vmx_mitigation ] ) ;
2018-11-25 18:33:40 +00:00
}
2018-08-05 14:07:45 +00:00
2022-08-09 15:32:02 +00:00
return sysfs_emit ( buf , " %s; VMX: %s, SMT %s \n " , L1TF_DEFAULT_MSG ,
l1tf_vmx_states [ l1tf_vmx_mitigation ] ,
sched_smt_active ( ) ? " vulnerable " : " disabled " ) ;
2018-07-13 14:23:16 +00:00
}
2019-11-04 11:22:02 +00:00
static ssize_t itlb_multihit_show_state ( char * buf )
{
2020-07-16 19:23:59 +00:00
if ( ! boot_cpu_has ( X86_FEATURE_MSR_IA32_FEAT_CTL ) | |
! boot_cpu_has ( X86_FEATURE_VMX ) )
2022-08-09 15:32:02 +00:00
return sysfs_emit ( buf , " KVM: Mitigation: VMX unsupported \n " ) ;
2020-07-16 19:23:59 +00:00
else if ( ! ( cr4_read_shadow ( ) & X86_CR4_VMXE ) )
2022-08-09 15:32:02 +00:00
return sysfs_emit ( buf , " KVM: Mitigation: VMX disabled \n " ) ;
2020-07-16 19:23:59 +00:00
else if ( itlb_multihit_kvm_mitigation )
2022-08-09 15:32:02 +00:00
return sysfs_emit ( buf , " KVM: Mitigation: Split huge pages \n " ) ;
2019-11-04 11:22:02 +00:00
else
2022-08-09 15:32:02 +00:00
return sysfs_emit ( buf , " KVM: Vulnerable \n " ) ;
2019-11-04 11:22:02 +00:00
}
2018-07-13 14:23:16 +00:00
# else
static ssize_t l1tf_show_state ( char * buf )
{
2022-08-09 15:32:02 +00:00
return sysfs_emit ( buf , " %s \n " , L1TF_DEFAULT_MSG ) ;
2018-07-13 14:23:16 +00:00
}
2019-11-04 11:22:01 +00:00
static ssize_t itlb_multihit_show_state ( char * buf )
{
2022-08-09 15:32:02 +00:00
return sysfs_emit ( buf , " Processor vulnerable \n " ) ;
2019-11-04 11:22:01 +00:00
}
2019-11-04 11:22:02 +00:00
# endif
2019-11-04 11:22:01 +00:00
2019-02-18 21:51:43 +00:00
static ssize_t mds_show_state ( char * buf )
{
2019-07-25 02:39:09 +00:00
if ( boot_cpu_has ( X86_FEATURE_HYPERVISOR ) ) {
2022-08-09 15:32:02 +00:00
return sysfs_emit ( buf , " %s; SMT Host state unknown \n " ,
mds_strings [ mds_mitigation ] ) ;
2019-02-18 21:51:43 +00:00
}
if ( boot_cpu_has ( X86_BUG_MSBDS_ONLY ) ) {
2022-08-09 15:32:02 +00:00
return sysfs_emit ( buf , " %s; SMT %s \n " , mds_strings [ mds_mitigation ] ,
( mds_mitigation = = MDS_MITIGATION_OFF ? " vulnerable " :
sched_smt_active ( ) ? " mitigated " : " disabled " ) ) ;
2019-02-18 21:51:43 +00:00
}
2022-08-09 15:32:02 +00:00
return sysfs_emit ( buf , " %s; SMT %s \n " , mds_strings [ mds_mitigation ] ,
sched_smt_active ( ) ? " vulnerable " : " disabled " ) ;
2019-02-18 21:51:43 +00:00
}
2019-10-23 10:19:51 +00:00
static ssize_t tsx_async_abort_show_state ( char * buf )
{
if ( ( taa_mitigation = = TAA_MITIGATION_TSX_DISABLED ) | |
( taa_mitigation = = TAA_MITIGATION_OFF ) )
2022-08-09 15:32:02 +00:00
return sysfs_emit ( buf , " %s \n " , taa_strings [ taa_mitigation ] ) ;
2019-10-23 10:19:51 +00:00
if ( boot_cpu_has ( X86_FEATURE_HYPERVISOR ) ) {
2022-08-09 15:32:02 +00:00
return sysfs_emit ( buf , " %s; SMT Host state unknown \n " ,
taa_strings [ taa_mitigation ] ) ;
2019-10-23 10:19:51 +00:00
}
2022-08-09 15:32:02 +00:00
return sysfs_emit ( buf , " %s; SMT %s \n " , taa_strings [ taa_mitigation ] ,
sched_smt_active ( ) ? " vulnerable " : " disabled " ) ;
2019-10-23 10:19:51 +00:00
}
2022-05-20 03:32:13 +00:00
static ssize_t mmio_stale_data_show_state ( char * buf )
{
2022-08-03 21:41:32 +00:00
if ( boot_cpu_has_bug ( X86_BUG_MMIO_UNKNOWN ) )
return sysfs_emit ( buf , " Unknown: No mitigations \n " ) ;
2022-05-20 03:32:13 +00:00
if ( mmio_mitigation = = MMIO_MITIGATION_OFF )
return sysfs_emit ( buf , " %s \n " , mmio_strings [ mmio_mitigation ] ) ;
if ( boot_cpu_has ( X86_FEATURE_HYPERVISOR ) ) {
return sysfs_emit ( buf , " %s; SMT Host state unknown \n " ,
mmio_strings [ mmio_mitigation ] ) ;
}
return sysfs_emit ( buf , " %s; SMT %s \n " , mmio_strings [ mmio_mitigation ] ,
sched_smt_active ( ) ? " vulnerable " : " disabled " ) ;
}
2018-11-25 18:33:32 +00:00
static char * stibp_state ( void )
{
2023-02-27 06:05:40 +00:00
if ( spectre_v2_in_eibrs_mode ( spectre_v2_enabled ) )
2018-11-25 18:33:33 +00:00
return " " ;
x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced IBRS.
When STIBP is unavailable or enhanced IBRS is available, Linux
force-disables the IBPB mitigation of Spectre-BTB even when simultaneous
multithreading is disabled. While attempts to enable IBPB using
prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, ...) fail with
EPERM, the seccomp syscall (or its prctl(PR_SET_SECCOMP, ...) equivalent)
which are used e.g. by Chromium or OpenSSH succeed with no errors but the
application remains silently vulnerable to cross-process Spectre v2 attacks
(classical BTB poisoning). At the same time the SYSFS reporting
(/sys/devices/system/cpu/vulnerabilities/spectre_v2) displays that IBPB is
conditionally enabled when in fact it is unconditionally disabled.
STIBP is useful only when SMT is enabled. When SMT is disabled and STIBP is
unavailable, it makes no sense to force-disable also IBPB, because IBPB
protects against cross-process Spectre-BTB attacks regardless of the SMT
state. At the same time since missing STIBP was only observed on AMD CPUs,
AMD does not recommend using STIBP, but recommends using IBPB, so disabling
IBPB because of missing STIBP goes directly against AMD's advice:
https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf
Similarly, enhanced IBRS is designed to protect cross-core BTB poisoning
and BTB-poisoning attacks from user space against kernel (and
BTB-poisoning attacks from guest against hypervisor), it is not designed
to prevent cross-process (or cross-VM) BTB poisoning between processes (or
VMs) running on the same core. Therefore, even with enhanced IBRS it is
necessary to flush the BTB during context-switches, so there is no reason
to force disable IBPB when enhanced IBRS is available.
Enable the prctl control of IBPB even when STIBP is unavailable or enhanced
IBRS is available.
Fixes: 7cc765a67d8e ("x86/speculation: Enable prctl mode for spectre_v2_user")
Signed-off-by: Anthony Steinhauser <asteinhauser@google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
2020-05-19 13:40:42 +00:00
switch ( spectre_v2_user_stibp ) {
2018-11-25 18:33:45 +00:00
case SPECTRE_V2_USER_NONE :
return " , STIBP: disabled " ;
case SPECTRE_V2_USER_STRICT :
return " , STIBP: forced " ;
2018-12-13 23:03:54 +00:00
case SPECTRE_V2_USER_STRICT_PREFERRED :
return " , STIBP: always-on " ;
x86/speculation: Add prctl() control for indirect branch speculation
Add the PR_SPEC_INDIRECT_BRANCH option for the PR_GET_SPECULATION_CTRL and
PR_SET_SPECULATION_CTRL prctls to allow fine grained per task control of
indirect branch speculation via STIBP and IBPB.
Invocations:
Check indirect branch speculation status with
- prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, 0, 0, 0);
Enable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE, 0, 0);
Disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE, 0, 0);
Force disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0);
See Documentation/userspace-api/spec_ctrl.rst.
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Casey Schaufler <casey.schaufler@intel.com>
Cc: Asit Mallick <asit.k.mallick@intel.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Jon Masters <jcm@redhat.com>
Cc: Waiman Long <longman9394@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Dave Stewart <david.c.stewart@intel.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20181125185005.866780996@linutronix.de
2018-11-25 18:33:53 +00:00
case SPECTRE_V2_USER_PRCTL :
2018-11-25 18:33:55 +00:00
case SPECTRE_V2_USER_SECCOMP :
2018-11-25 18:33:54 +00:00
if ( static_key_enabled ( & switch_to_cond_stibp ) )
return " , STIBP: conditional " ;
2018-11-25 18:33:45 +00:00
}
return " " ;
2018-11-25 18:33:32 +00:00
}
static char * ibpb_state ( void )
{
2018-11-25 18:33:49 +00:00
if ( boot_cpu_has ( X86_FEATURE_IBPB ) ) {
2018-11-25 18:33:54 +00:00
if ( static_key_enabled ( & switch_mm_always_ibpb ) )
2018-11-25 18:33:49 +00:00
return " , IBPB: always-on " ;
2018-11-25 18:33:54 +00:00
if ( static_key_enabled ( & switch_mm_cond_ibpb ) )
return " , IBPB: conditional " ;
return " , IBPB: disabled " ;
2018-11-25 18:33:49 +00:00
}
return " " ;
2018-11-25 18:33:32 +00:00
}
x86/speculation: Add RSB VM Exit protections
tl;dr: The Enhanced IBRS mitigation for Spectre v2 does not work as
documented for RET instructions after VM exits. Mitigate it with a new
one-entry RSB stuffing mechanism and a new LFENCE.
== Background ==
Indirect Branch Restricted Speculation (IBRS) was designed to help
mitigate Branch Target Injection and Speculative Store Bypass, i.e.
Spectre, attacks. IBRS prevents software run in less privileged modes
from affecting branch prediction in more privileged modes. IBRS requires
the MSR to be written on every privilege level change.
To overcome some of the performance issues of IBRS, Enhanced IBRS was
introduced. eIBRS is an "always on" IBRS, in other words, just turn
it on once instead of writing the MSR on every privilege level change.
When eIBRS is enabled, more privileged modes should be protected from
less privileged modes, including protecting VMMs from guests.
== Problem ==
Here's a simplification of how guests are run on Linux' KVM:
void run_kvm_guest(void)
{
// Prepare to run guest
VMRESUME();
// Clean up after guest runs
}
The execution flow for that would look something like this to the
processor:
1. Host-side: call run_kvm_guest()
2. Host-side: VMRESUME
3. Guest runs, does "CALL guest_function"
4. VM exit, host runs again
5. Host might make some "cleanup" function calls
6. Host-side: RET from run_kvm_guest()
Now, when back on the host, there are a couple of possible scenarios of
post-guest activity the host needs to do before executing host code:
* on pre-eIBRS hardware (legacy IBRS, or nothing at all), the RSB is not
touched and Linux has to do a 32-entry stuffing.
* on eIBRS hardware, VM exit with IBRS enabled, or restoring the host
IBRS=1 shortly after VM exit, has a documented side effect of flushing
the RSB except in this PBRSB situation where the software needs to stuff
the last RSB entry "by hand".
IOW, with eIBRS supported, host RET instructions should no longer be
influenced by guest behavior after the host retires a single CALL
instruction.
However, if the RET instructions are "unbalanced" with CALLs after a VM
exit as is the RET in #6, it might speculatively use the address for the
instruction after the CALL in #3 as an RSB prediction. This is a problem
since the (untrusted) guest controls this address.
Balanced CALL/RET instruction pairs such as in step #5 are not affected.
== Solution ==
The PBRSB issue affects a wide variety of Intel processors which
support eIBRS. But not all of them need mitigation. Today,
X86_FEATURE_RSB_VMEXIT triggers an RSB filling sequence that mitigates
PBRSB. Systems setting RSB_VMEXIT need no further mitigation - i.e.,
eIBRS systems which enable legacy IBRS explicitly.
However, such systems (X86_FEATURE_IBRS_ENHANCED) do not set RSB_VMEXIT
and most of them need a new mitigation.
Therefore, introduce a new feature flag X86_FEATURE_RSB_VMEXIT_LITE
which triggers a lighter-weight PBRSB mitigation versus RSB_VMEXIT.
The lighter-weight mitigation performs a CALL instruction which is
immediately followed by a speculative execution barrier (INT3). This
steers speculative execution to the barrier -- just like a retpoline
-- which ensures that speculation can never reach an unbalanced RET.
Then, ensure this CALL is retired before continuing execution with an
LFENCE.
In other words, the window of exposure is opened at VM exit where RET
behavior is troublesome. While the window is open, force RSB predictions
sampling for RET targets to a dead end at the INT3. Close the window
with the LFENCE.
There is a subset of eIBRS systems which are not vulnerable to PBRSB.
Add these systems to the cpu_vuln_whitelist[] as NO_EIBRS_PBRSB.
Future systems that aren't vulnerable will set ARCH_CAP_PBRSB_NO.
[ bp: Massage, incorporate review comments from Andy Cooper. ]
Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Co-developed-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
2022-08-02 22:47:01 +00:00
static char * pbrsb_eibrs_state ( void )
{
if ( boot_cpu_has_bug ( X86_BUG_EIBRS_PBRSB ) ) {
if ( boot_cpu_has ( X86_FEATURE_RSB_VMEXIT_LITE ) | |
boot_cpu_has ( X86_FEATURE_RSB_VMEXIT ) )
return " , PBRSB-eIBRS: SW sequence " ;
else
return " , PBRSB-eIBRS: Vulnerable " ;
} else {
return " , PBRSB-eIBRS: Not affected " ;
}
}
2022-02-18 19:49:08 +00:00
static ssize_t spectre_v2_show_state ( char * buf )
{
2022-02-25 22:31:49 +00:00
if ( spectre_v2_enabled = = SPECTRE_V2_LFENCE )
2022-08-09 15:32:02 +00:00
return sysfs_emit ( buf , " Vulnerable: LFENCE \n " ) ;
2022-02-25 22:31:49 +00:00
2022-02-18 19:49:08 +00:00
if ( spectre_v2_enabled = = SPECTRE_V2_EIBRS & & unprivileged_ebpf_enabled ( ) )
2022-08-09 15:32:02 +00:00
return sysfs_emit ( buf , " Vulnerable: eIBRS with unprivileged eBPF \n " ) ;
2022-02-25 22:32:28 +00:00
if ( sched_smt_active ( ) & & unprivileged_ebpf_enabled ( ) & &
spectre_v2_enabled = = SPECTRE_V2_EIBRS_LFENCE )
2022-08-09 15:32:02 +00:00
return sysfs_emit ( buf , " Vulnerable: eIBRS+LFENCE with unprivileged eBPF and SMT \n " ) ;
2022-02-18 19:49:08 +00:00
2022-08-09 15:32:02 +00:00
return sysfs_emit ( buf , " %s%s%s%s%s%s%s \n " ,
spectre_v2_strings [ spectre_v2_enabled ] ,
ibpb_state ( ) ,
boot_cpu_has ( X86_FEATURE_USE_IBRS_FW ) ? " , IBRS_FW " : " " ,
stibp_state ( ) ,
boot_cpu_has ( X86_FEATURE_RSB_CTXSW ) ? " , RSB filling " : " " ,
pbrsb_eibrs_state ( ) ,
spectre_v2_module_string ( ) ) ;
2022-02-18 19:49:08 +00:00
}
2020-04-16 15:54:04 +00:00
static ssize_t srbds_show_state ( char * buf )
{
2022-08-09 15:32:02 +00:00
return sysfs_emit ( buf , " %s \n " , srbds_strings [ srbds_mitigation ] ) ;
2020-04-16 15:54:04 +00:00
}
2022-06-14 21:15:49 +00:00
static ssize_t retbleed_show_state ( char * buf )
{
x86/bugs: Enable STIBP for IBPB mitigated RETBleed
AMD's "Technical Guidance for Mitigating Branch Type Confusion,
Rev. 1.0 2022-07-12" whitepaper, under section 6.1.2 "IBPB On
Privileged Mode Entry / SMT Safety" says:
Similar to the Jmp2Ret mitigation, if the code on the sibling thread
cannot be trusted, software should set STIBP to 1 or disable SMT to
ensure SMT safety when using this mitigation.
So, like already being done for retbleed=unret, and now also for
retbleed=ibpb, force STIBP on machines that have it, and report its SMT
vulnerability status accordingly.
[ bp: Remove the "we" and remove "[AMD]" applicability parameter which
doesn't work here. ]
Fixes: 3ebc17006888 ("x86/bugs: Add retbleed=ibpb")
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: stable@vger.kernel.org # 5.10, 5.15, 5.19
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
Link: https://lore.kernel.org/r/20220804192201.439596-1-kim.phillips@amd.com
2022-08-08 14:32:33 +00:00
if ( retbleed_mitigation = = RETBLEED_MITIGATION_UNRET | |
retbleed_mitigation = = RETBLEED_MITIGATION_IBPB ) {
2022-08-09 15:32:02 +00:00
if ( boot_cpu_data . x86_vendor ! = X86_VENDOR_AMD & &
boot_cpu_data . x86_vendor ! = X86_VENDOR_HYGON )
return sysfs_emit ( buf , " Vulnerable: untrained return thunk / IBPB on non-AMD based uarch \n " ) ;
2022-06-14 21:15:51 +00:00
2022-08-09 15:32:02 +00:00
return sysfs_emit ( buf , " %s; SMT %s \n " , retbleed_strings [ retbleed_mitigation ] ,
! sched_smt_active ( ) ? " disabled " :
spectre_v2_user_stibp = = SPECTRE_V2_USER_STRICT | |
spectre_v2_user_stibp = = SPECTRE_V2_USER_STRICT_PREFERRED ?
" enabled with STIBP protection " : " vulnerable " ) ;
2022-06-14 21:15:51 +00:00
}
2022-06-14 21:15:50 +00:00
2022-08-09 15:32:02 +00:00
return sysfs_emit ( buf , " %s \n " , retbleed_strings [ retbleed_mitigation ] ) ;
2022-06-14 21:15:49 +00:00
}
2018-05-10 20:47:32 +00:00
static ssize_t cpu_show_common ( struct device * dev , struct device_attribute * attr ,
2018-05-11 20:50:35 +00:00
char * buf , unsigned int bug )
2018-01-07 21:48:01 +00:00
{
2018-04-26 02:04:17 +00:00
if ( ! boot_cpu_has_bug ( bug ) )
2022-08-09 15:32:02 +00:00
return sysfs_emit ( buf , " Not affected \n " ) ;
2018-04-26 02:04:17 +00:00
switch ( bug ) {
case X86_BUG_CPU_MELTDOWN :
if ( boot_cpu_has ( X86_FEATURE_PTI ) )
2022-08-09 15:32:02 +00:00
return sysfs_emit ( buf , " Mitigation: PTI \n " ) ;
2018-04-26 02:04:17 +00:00
2018-06-18 07:59:54 +00:00
if ( hypervisor_is_type ( X86_HYPER_XEN_PV ) )
2022-08-09 15:32:02 +00:00
return sysfs_emit ( buf , " Unknown (XEN PV detected, hypervisor mitigation required) \ n " ) ;
2018-06-18 07:59:54 +00:00
2018-04-26 02:04:17 +00:00
break ;
case X86_BUG_SPECTRE_V1 :
2022-08-09 15:32:02 +00:00
return sysfs_emit ( buf , " %s \n " , spectre_v1_strings [ spectre_v1_mitigation ] ) ;
2018-04-26 02:04:17 +00:00
case X86_BUG_SPECTRE_V2 :
2022-02-18 19:49:08 +00:00
return spectre_v2_show_state ( buf ) ;
2018-04-26 02:04:17 +00:00
2018-04-26 02:04:21 +00:00
case X86_BUG_SPEC_STORE_BYPASS :
2022-08-09 15:32:02 +00:00
return sysfs_emit ( buf , " %s \n " , ssb_strings [ ssb_mode ] ) ;
2018-04-26 02:04:21 +00:00
2018-06-13 22:48:26 +00:00
case X86_BUG_L1TF :
if ( boot_cpu_has ( X86_FEATURE_L1TF_PTEINV ) )
2018-07-13 14:23:16 +00:00
return l1tf_show_state ( buf ) ;
2018-06-13 22:48:26 +00:00
break ;
2019-02-18 21:51:43 +00:00
case X86_BUG_MDS :
return mds_show_state ( buf ) ;
2019-10-23 10:19:51 +00:00
case X86_BUG_TAA :
return tsx_async_abort_show_state ( buf ) ;
2019-11-04 11:22:01 +00:00
case X86_BUG_ITLB_MULTIHIT :
return itlb_multihit_show_state ( buf ) ;
2020-04-16 15:54:04 +00:00
case X86_BUG_SRBDS :
return srbds_show_state ( buf ) ;
2022-05-20 03:32:13 +00:00
case X86_BUG_MMIO_STALE_DATA :
2022-08-03 21:41:32 +00:00
case X86_BUG_MMIO_UNKNOWN :
2022-05-20 03:32:13 +00:00
return mmio_stale_data_show_state ( buf ) ;
2022-06-14 21:15:49 +00:00
case X86_BUG_RETBLEED :
return retbleed_show_state ( buf ) ;
2018-04-26 02:04:17 +00:00
default :
break ;
}
2022-08-09 15:32:02 +00:00
return sysfs_emit ( buf , " Vulnerable \n " ) ;
2018-01-07 21:48:01 +00:00
}
2018-04-26 02:04:17 +00:00
ssize_t cpu_show_meltdown ( struct device * dev , struct device_attribute * attr , char * buf )
{
return cpu_show_common ( dev , attr , buf , X86_BUG_CPU_MELTDOWN ) ;
}
2018-02-13 08:03:08 +00:00
ssize_t cpu_show_spectre_v1 ( struct device * dev , struct device_attribute * attr , char * buf )
2018-01-07 21:48:01 +00:00
{
2018-04-26 02:04:17 +00:00
return cpu_show_common ( dev , attr , buf , X86_BUG_SPECTRE_V1 ) ;
2018-01-07 21:48:01 +00:00
}
2018-02-13 08:03:08 +00:00
ssize_t cpu_show_spectre_v2 ( struct device * dev , struct device_attribute * attr , char * buf )
2018-01-07 21:48:01 +00:00
{
2018-04-26 02:04:17 +00:00
return cpu_show_common ( dev , attr , buf , X86_BUG_SPECTRE_V2 ) ;
2018-01-07 21:48:01 +00:00
}
2018-04-26 02:04:20 +00:00
ssize_t cpu_show_spec_store_bypass ( struct device * dev , struct device_attribute * attr , char * buf )
{
return cpu_show_common ( dev , attr , buf , X86_BUG_SPEC_STORE_BYPASS ) ;
}
2018-06-13 22:48:26 +00:00
ssize_t cpu_show_l1tf ( struct device * dev , struct device_attribute * attr , char * buf )
{
return cpu_show_common ( dev , attr , buf , X86_BUG_L1TF ) ;
}
2019-02-18 21:51:43 +00:00
ssize_t cpu_show_mds ( struct device * dev , struct device_attribute * attr , char * buf )
{
return cpu_show_common ( dev , attr , buf , X86_BUG_MDS ) ;
}
2019-10-23 10:19:51 +00:00
ssize_t cpu_show_tsx_async_abort ( struct device * dev , struct device_attribute * attr , char * buf )
{
return cpu_show_common ( dev , attr , buf , X86_BUG_TAA ) ;
}
2019-11-04 11:22:01 +00:00
ssize_t cpu_show_itlb_multihit ( struct device * dev , struct device_attribute * attr , char * buf )
{
return cpu_show_common ( dev , attr , buf , X86_BUG_ITLB_MULTIHIT ) ;
}
2020-04-16 15:54:04 +00:00
ssize_t cpu_show_srbds ( struct device * dev , struct device_attribute * attr , char * buf )
{
return cpu_show_common ( dev , attr , buf , X86_BUG_SRBDS ) ;
}
2022-05-20 03:32:13 +00:00
ssize_t cpu_show_mmio_stale_data ( struct device * dev , struct device_attribute * attr , char * buf )
{
2022-08-03 21:41:32 +00:00
if ( boot_cpu_has_bug ( X86_BUG_MMIO_UNKNOWN ) )
return cpu_show_common ( dev , attr , buf , X86_BUG_MMIO_UNKNOWN ) ;
else
return cpu_show_common ( dev , attr , buf , X86_BUG_MMIO_STALE_DATA ) ;
2022-05-20 03:32:13 +00:00
}
2022-06-14 21:15:49 +00:00
ssize_t cpu_show_retbleed ( struct device * dev , struct device_attribute * attr , char * buf )
{
return cpu_show_common ( dev , attr , buf , X86_BUG_RETBLEED ) ;
}
2018-01-07 21:48:01 +00:00
# endif