linux.git/arch/x86/kernel/cpu/bugs.c, branch v5.10.258

x86/bugs: Fix reporting of LFENCE retpoline

2025-12-06T21:08:06+00:00

[ Upstream commit d1cc1baef67ac6c09b74629ca053bf3fb812f7dc ]

The LFENCE retpoline mitigation is not secure but the kernel prints
inconsistent messages about this fact.  The dmesg log says 'Mitigation:
LFENCE', implying the system is mitigated.  But sysfs reports 'Vulnerable:
LFENCE' implying the system (correctly) is not mitigated.

Fix this by printing a consistent 'Vulnerable: LFENCE' string everywhere
when this mitigation is selected.

Signed-off-by: David Kaplan 
Signed-off-by: Borislav Petkov (AMD) 
Link: https://lore.kernel.org/20250915134706.3201818-1-david.kaplan@amd.com
Signed-off-by: Sasha Levin

x86/vmscape: Warn when STIBP is disabled with SMT

2025-09-11T15:16:06+00:00

commit b7cc9887231526ca4fa89f3fa4119e47c2dc7b1e upstream.

Cross-thread attacks are generally harder as they require the victim to be
co-located on a core. However, with VMSCAPE the adversary targets belong to
the same guest execution, that are more likely to get co-located. In
particular, a thread that is currently executing userspace hypervisor
(after the IBPB) may still be targeted by a guest execution from a sibling
thread.

Issue a warning about the potential risk, except when:

- SMT is disabled
- STIBP is enabled system-wide
- Intel eIBRS is enabled (which implies STIBP protection)

Signed-off-by: Pawan Gupta 
Signed-off-by: Dave Hansen 
Signed-off-by: Amit Shah 
Signed-off-by: Greg Kroah-Hartman

x86/bugs: Move cpu_bugs_smt_update() down

2025-09-11T15:16:06+00:00

commit 6449f5baf9c78a7a442d64f4a61378a21c5db113 upstream.

cpu_bugs_smt_update() uses global variables from different mitigations. For
SMT updates it can't currently use vmscape_mitigation that is defined after
it.

Since cpu_bugs_smt_update() depends on many other mitigations, move it
after all mitigations are defined. With that, it can use vmscape_mitigation
in a moment.

No functional change.

Signed-off-by: Pawan Gupta 
Signed-off-by: Dave Hansen 
Reviewed-by: Dave Hansen 
Signed-off-by: Amit Shah 
Signed-off-by: Greg Kroah-Hartman

x86/vmscape: Enable the mitigation

2025-09-11T15:16:06+00:00

commit 556c1ad666ad90c50ec8fccb930dd5046cfbecfb upstream.

Enable the previously added mitigation for VMscape. Add the cmdline
vmscape={off|ibpb|force} and sysfs reporting.

Signed-off-by: Pawan Gupta 
Signed-off-by: Dave Hansen 
Reviewed-by: Borislav Petkov (AMD) 
Reviewed-by: Dave Hansen 
Signed-off-by: Amit Shah 
Signed-off-by: Greg Kroah-Hartman

x86/vmscape: Add conditional IBPB mitigation

2025-09-11T15:16:06+00:00

commit 2f8f173413f1cbf52660d04df92d0069c4306d25 upstream.

VMSCAPE is a vulnerability that exploits insufficient branch predictor
isolation between a guest and a userspace hypervisor (like QEMU). Existing
mitigations already protect kernel/KVM from a malicious guest. Userspace
can additionally be protected by flushing the branch predictors after a
VMexit.

Since it is the userspace that consumes the poisoned branch predictors,
conditionally issue an IBPB after a VMexit and before returning to
userspace. Workloads that frequently switch between hypervisor and
userspace will incur the most overhead from the new IBPB.

This new IBPB is not integrated with the existing IBPB sites. For
instance, a task can use the existing speculation control prctl() to
get an IBPB at context switch time. With this implementation, the
IBPB is doubled up: one at context switch and another before running
userspace.

The intent is to integrate and optimize these cases post-embargo.

[ dhansen: elaborate on suboptimal IBPB solution ]

Suggested-by: Dave Hansen 
Signed-off-by: Pawan Gupta 
Signed-off-by: Dave Hansen 
Reviewed-by: Dave Hansen 
Reviewed-by: Borislav Petkov (AMD) 
Acked-by: Sean Christopherson 
[Amit: Use CPUID word 22 instead of 21 for the 5.10 backport]
Signed-off-by: Amit Shah 
Signed-off-by: Greg Kroah-Hartman

x86/bugs: Avoid warning when overriding return thunk

2025-08-28T14:22:41+00:00

[ Upstream commit 9f85fdb9fc5a1bd308a10a0a7d7e34f2712ba58b ]

The purpose of the warning is to prevent an unexpected change to the return
thunk mitigation. However, there are legitimate cases where the return
thunk is intentionally set more than once. For example, ITS and SRSO both
can set the return thunk after retbleed has set it. In both the cases
retbleed is still mitigated.

Replace the warning with an info about the active return thunk.

Suggested-by: Borislav Petkov 
Signed-off-by: Pawan Gupta 
Signed-off-by: Borislav Petkov (AMD) 
Link: https://lore.kernel.org/20250611-eibrs-fix-v4-3-5ff86cac6c61@linux.intel.com
Signed-off-by: Sasha Levin

x86/bugs: Add a Transient Scheduler Attacks mitigation

2025-07-17T16:28:00+00:00

From: "Borislav Petkov (AMD)" 

Commit d8010d4ba43e9f790925375a7de100604a5e2dba upstream.

Add the required features detection glue to bugs.c et all in order to
support the TSA mitigation.

Co-developed-by: Kim Phillips 
Signed-off-by: Kim Phillips 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Pawan Gupta 
Signed-off-by: Greg Kroah-Hartman

x86/bugs: Rename MDS machinery to something more generic

2025-07-17T16:28:00+00:00

From: "Borislav Petkov (AMD)" 

Commit f9af88a3d384c8b55beb5dc5483e5da0135fadbd upstream.

It will be used by other x86 mitigations.

No functional changes.

Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Pawan Gupta 
Signed-off-by: Greg Kroah-Hartman

x86/its: Add "vmexit" option to skip mitigation on some CPUs

2025-07-17T16:27:56+00:00

commit 2665281a07e19550944e8354a2024635a7b2714a upstream.

Ice Lake generation CPUs are not affected by guest/host isolation part of
ITS. If a user is only concerned about KVM guests, they can now choose a
new cmdline option "vmexit" that will not deploy the ITS mitigation when
CPU is not affected by guest/host isolation. This saves the performance
overhead of ITS mitigation on Ice Lake gen CPUs.

When "vmexit" option selected, if the CPU is affected by ITS guest/host
isolation, the default ITS mitigation is deployed.

Signed-off-by: Dave Hansen 
Reviewed-by: Josh Poimboeuf 
Reviewed-by: Alexandre Chartre 
Signed-off-by: Pawan Gupta 
Signed-off-by: Greg Kroah-Hartman

x86/its: Enable Indirect Target Selection mitigation

2025-07-17T16:27:55+00:00

commit f4818881c47fd91fcb6d62373c57c7844e3de1c0 upstream.

Indirect Target Selection (ITS) is a bug in some pre-ADL Intel CPUs with
eIBRS. It affects prediction of indirect branch and RETs in the
lower half of cacheline. Due to ITS such branches may get wrongly predicted
to a target of (direct or indirect) branch that is located in the upper
half of the cacheline.

Scope of impact
===============

Guest/host isolation
--------------------
When eIBRS is used for guest/host isolation, the indirect branches in the
VMM may still be predicted with targets corresponding to branches in the
guest.

Intra-mode
----------
cBPF or other native gadgets can be used for intra-mode training and
disclosure using ITS.

User/kernel isolation
---------------------
When eIBRS is enabled user/kernel isolation is not impacted.

Indirect Branch Prediction Barrier (IBPB)
-----------------------------------------
After an IBPB, indirect branches may be predicted with targets
corresponding to direct branches which were executed prior to IBPB. This is
mitigated by a microcode update.

Add cmdline parameter indirect_target_selection=off|on|force to control the
mitigation to relocate the affected branches to an ITS-safe thunk i.e.
located in the upper half of cacheline. Also add the sysfs reporting.

When retpoline mitigation is deployed, ITS safe-thunks are not needed,
because retpoline sequence is already ITS-safe. Similarly, when call depth
tracking (CDT) mitigation is deployed (retbleed=stuff), ITS safe return
thunk is not used, as CDT prevents RSB-underflow.

To not overcomplicate things, ITS mitigation is not supported with
spectre-v2 lfence;jmp mitigation. Moreover, it is less practical to deploy
lfence;jmp mitigation on ITS affected parts anyways.

Signed-off-by: Dave Hansen 
Reviewed-by: Josh Poimboeuf 
Reviewed-by: Alexandre Chartre 
Signed-off-by: Pawan Gupta 
Signed-off-by: Greg Kroah-Hartman