1 2.. SPDX-License-Identifier: GPL-2.0 3 4Cross-Thread Return Address Predictions 5======================================= 6 7Certain AMD and Hygon processors are subject to a cross-thread return address 8predictions vulnerability. When running in SMT mode and one sibling thread 9transitions out of C0 state, the other sibling thread could use return target 10predictions from the sibling thread that transitioned out of C0. 11 12The Spectre v2 mitigations protect the Linux kernel, as it fills the return 13address prediction entries with safe targets when context switching to the idle 14thread. However, KVM does allow a VMM to prevent exiting guest mode when 15transitioning out of C0. This could result in a guest-controlled return target 16being consumed by the sibling thread. 17 18Affected processors 19------------------- 20 21The following CPUs are vulnerable: 22 23 - AMD Family 17h processors 24 - Hygon Family 18h processors 25 26Related CVEs 27------------ 28 29The following CVE entry is related to this issue: 30 31 ============== ======================================= 32 CVE-2022-27672 Cross-Thread Return Address Predictions 33 ============== ======================================= 34 35Problem 36------- 37 38Affected SMT-capable processors support 1T and 2T modes of execution when SMT 39is enabled. In 2T mode, both threads in a core are executing code. For the 40processor core to enter 1T mode, it is required that one of the threads 41requests to transition out of the C0 state. This can be communicated with the 42HLT instruction or with an MWAIT instruction that requests non-C0. 43When the thread re-enters the C0 state, the processor transitions back 44to 2T mode, assuming the other thread is also still in C0 state. 45 46In affected processors, the return address predictor (RAP) is partitioned 47depending on the SMT mode. For instance, in 2T mode each thread uses a private 4816-entry RAP, but in 1T mode, the active thread uses a 32-entry RAP. Upon 49transition between 1T/2T mode, the RAP contents are not modified but the RAP 50pointers (which control the next return target to use for predictions) may 51change. This behavior may result in return targets from one SMT thread being 52used by RET predictions in the sibling thread following a 1T/2T switch. In 53particular, a RET instruction executed immediately after a transition to 1T may 54use a return target from the thread that just became idle. In theory, this 55could lead to information disclosure if the return targets used do not come 56from trustworthy code. 57 58Attack scenarios 59---------------- 60 61An attack can be mounted on affected processors by performing a series of CALL 62instructions with targeted return locations and then transitioning out of C0 63state. 64 65Mitigation mechanism 66-------------------- 67 68Before entering idle state, the kernel context switches to the idle thread. The 69context switch fills the RAP entries (referred to as the RSB in Linux) with safe 70targets by performing a sequence of CALL instructions. 71 72Prevent a guest VM from directly putting the processor into an idle state by 73intercepting HLT and MWAIT instructions. 74 75Both mitigations are required to fully address this issue. 76 77Mitigation control on the kernel command line 78--------------------------------------------- 79 80Use existing Spectre v2 mitigations that will fill the RSB on context switch. 81 82Mitigation control for KVM - module parameter 83--------------------------------------------- 84 85By default, the KVM hypervisor mitigates this issue by intercepting guest 86attempts to transition out of C0. A VMM can use the KVM_CAP_X86_DISABLE_EXITS 87capability to override those interceptions, but since this is not common, the 88mitigation that covers this path is not enabled by default. 89 90The mitigation for the KVM_CAP_X86_DISABLE_EXITS capability can be turned on 91using the boolean module parameter mitigate_smt_rsb, e.g. ``kvm.mitigate_smt_rsb=1``. 92