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