1.. SPDX-License-Identifier: GPL-2.0 2 3Speculative Return Stack Overflow (SRSO) 4======================================== 5 6This is a mitigation for the speculative return stack overflow (SRSO) 7vulnerability found on AMD processors. The mechanism is by now the well 8known scenario of poisoning CPU functional units - the Branch Target 9Buffer (BTB) and Return Address Predictor (RAP) in this case - and then 10tricking the elevated privilege domain (the kernel) into leaking 11sensitive data. 12 13AMD CPUs predict RET instructions using a Return Address Predictor (aka 14Return Address Stack/Return Stack Buffer). In some cases, a non-architectural 15CALL instruction (i.e., an instruction predicted to be a CALL but is 16not actually a CALL) can create an entry in the RAP which may be used 17to predict the target of a subsequent RET instruction. 18 19The specific circumstances that lead to this varies by microarchitecture 20but the concern is that an attacker can mis-train the CPU BTB to predict 21non-architectural CALL instructions in kernel space and use this to 22control the speculative target of a subsequent kernel RET, potentially 23leading to information disclosure via a speculative side-channel. 24 25The issue is tracked under CVE-2023-20569. 26 27Affected processors 28------------------- 29 30AMD Zen, generations 1-4. That is, all families 0x17 and 0x19. Older 31processors have not been investigated. 32 33System information and options 34------------------------------ 35 36First of all, it is required that the latest microcode be loaded for 37mitigations to be effective. 38 39The sysfs file showing SRSO mitigation status is: 40 41 /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow 42 43The possible values in this file are: 44 45 - 'Not affected' The processor is not vulnerable 46 47 - 'Vulnerable: no microcode' The processor is vulnerable, no 48 microcode extending IBPB functionality 49 to address the vulnerability has been 50 applied. 51 52 - 'Mitigation: microcode' Extended IBPB functionality microcode 53 patch has been applied. It does not 54 address User->Kernel and Guest->Host 55 transitions protection but it does 56 address User->User and VM->VM attack 57 vectors. 58 59 (spec_rstack_overflow=microcode) 60 61 - 'Mitigation: safe RET' Software-only mitigation. It complements 62 the extended IBPB microcode patch 63 functionality by addressing User->Kernel 64 and Guest->Host transitions protection. 65 66 Selected by default or by 67 spec_rstack_overflow=safe-ret 68 69 - 'Mitigation: IBPB' Similar protection as "safe RET" above 70 but employs an IBPB barrier on privilege 71 domain crossings (User->Kernel, 72 Guest->Host). 73 74 (spec_rstack_overflow=ibpb) 75 76 - 'Mitigation: IBPB on VMEXIT' Mitigation addressing the cloud provider 77 scenario - the Guest->Host transitions 78 only. 79 80 (spec_rstack_overflow=ibpb-vmexit) 81 82In order to exploit vulnerability, an attacker needs to: 83 84 - gain local access on the machine 85 86 - break kASLR 87 88 - find gadgets in the running kernel in order to use them in the exploit 89 90 - potentially create and pin an additional workload on the sibling 91 thread, depending on the microarchitecture (not necessary on fam 0x19) 92 93 - run the exploit 94 95Considering the performance implications of each mitigation type, the 96default one is 'Mitigation: safe RET' which should take care of most 97attack vectors, including the local User->Kernel one. 98 99As always, the user is advised to keep her/his system up-to-date by 100applying software updates regularly. 101 102The default setting will be reevaluated when needed and especially when 103new attack vectors appear. 104 105As one can surmise, 'Mitigation: safe RET' does come at the cost of some 106performance depending on the workload. If one trusts her/his userspace 107and does not want to suffer the performance impact, one can always 108disable the mitigation with spec_rstack_overflow=off. 109 110Similarly, 'Mitigation: IBPB' is another full mitigation type employing 111an indrect branch prediction barrier after having applied the required 112microcode patch for one's system. This mitigation comes also at 113a performance cost. 114 115Mitigation: safe RET 116-------------------- 117 118The mitigation works by ensuring all RET instructions speculate to 119a controlled location, similar to how speculation is controlled in the 120retpoline sequence. To accomplish this, the __x86_return_thunk forces 121the CPU to mispredict every function return using a 'safe return' 122sequence. 123 124To ensure the safety of this mitigation, the kernel must ensure that the 125safe return sequence is itself free from attacker interference. In Zen3 126and Zen4, this is accomplished by creating a BTB alias between the 127untraining function srso_alias_untrain_ret() and the safe return 128function srso_alias_safe_ret() which results in evicting a potentially 129poisoned BTB entry and using that safe one for all function returns. 130 131In older Zen1 and Zen2, this is accomplished using a reinterpretation 132technique similar to Retbleed one: srso_untrain_ret() and 133srso_safe_ret(). 134