Documentation/admin-guide/hw-vuln/srso.rst

   1 .. SPDX-License-Identifier: GPL-2.0
   2
   3 Speculative Return Stack Overflow (SRSO)
   4 ========================================
   5
   6 This is a mitigation for the speculative return stack overflow (SRSO)
   7 vulnerability found on AMD processors. The mechanism is by now the well
   8 known scenario of poisoning CPU functional units - the Branch Target
   9 Buffer (BTB) and Return Address Predictor (RAP) in this case - and then
  10 tricking the elevated privilege domain (the kernel) into leaking
  11 sensitive data.
  12
  13 AMD CPUs predict RET instructions using a Return Address Predictor (aka
  14 Return Address Stack/Return Stack Buffer). In some cases, a non-architectural
  15 CALL instruction (i.e., an instruction predicted to be a CALL but is
  16 not actually a CALL) can create an entry in the RAP which may be used
  17 to predict the target of a subsequent RET instruction.
  18
  19 The specific circumstances that lead to this varies by microarchitecture
  20 but the concern is that an attacker can mis-train the CPU BTB to predict
  21 non-architectural CALL instructions in kernel space and use this to
  22 control the speculative target of a subsequent kernel RET, potentially
  23 leading to information disclosure via a speculative side-channel.
  24
  25 The issue is tracked under CVE-2023-20569.
  26
  27 Affected processors
  28 -------------------
  29
  30 AMD Zen, generations 1-4. That is, all families 0x17 and 0x19. Older
  31 processors have not been investigated.
  32
  33 System information and options
  34 ------------------------------
  35
  36 First of all, it is required that the latest microcode be loaded for
  37 mitigations to be effective.
  38
  39 The sysfs file showing SRSO mitigation status is:
  40
  41   /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow
  42
  43 The 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
  82 In 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
  95 Considering the performance implications of each mitigation type, the
  96 default one is 'Mitigation: safe RET' which should take care of most
  97 attack vectors, including the local User->Kernel one.
  98
  99 As always, the user is advised to keep her/his system up-to-date by
 100 applying software updates regularly.
 101
 102 The default setting will be reevaluated when needed and especially when
 103 new attack vectors appear.
 104
 105 As one can surmise, 'Mitigation: safe RET' does come at the cost of some
 106 performance depending on the workload. If one trusts her/his userspace
 107 and does not want to suffer the performance impact, one can always
 108 disable the mitigation with spec_rstack_overflow=off.
 109
 110 Similarly, 'Mitigation: IBPB' is another full mitigation type employing
 111 an indrect branch prediction barrier after having applied the required
 112 microcode patch for one's system. This mitigation comes also at
 113 a performance cost.
 114
 115 Mitigation: safe RET
 116 --------------------
 117
 118 The mitigation works by ensuring all RET instructions speculate to
 119 a controlled location, similar to how speculation is controlled in the
 120 retpoline sequence.  To accomplish this, the __x86_return_thunk forces
 121 the CPU to mispredict every function return using a 'safe return'
 122 sequence.
 123
 124 To ensure the safety of this mitigation, the kernel must ensure that the
 125 safe return sequence is itself free from attacker interference.  In Zen3
 126 and Zen4, this is accomplished by creating a BTB alias between the
 127 untraining function srso_alias_untrain_ret() and the safe return
 128 function srso_alias_safe_ret() which results in evicting a potentially
 129 poisoned BTB entry and using that safe one for all function returns.
 130
 131 In older Zen1 and Zen2, this is accomplished using a reinterpretation
 132 technique similar to Retbleed one: srso_untrain_ret() and
 133 srso_safe_ret().