€•gŽ      Œsphinx.addnodes”Œdocument”“”)”}”(Œ	rawsource”Œ ”Œchildren”]”(Œtranslations”ŒLanguagesNode”“”)”}”(hhh]”(h Œpending_xref”“”)”}”(hhh]”Œdocutils.nodes”ŒText”“”ŒChinese (Simplified)”…””}”Œparent”hsbaŒ
attributes”}”(Œids”]”Œclasses”]”Œnames”]”Œdupnames”]”Œbackrefs”]”Œ	refdomain”Œstd”Œreftype”Œdoc”Œ	reftarget”Œ,/translations/zh_CN/admin-guide/hw-vuln/srso”Œmodname”NŒ	classname”NŒrefexplicit”ˆuŒtagname”hhhubh)”}”(hhh]”hŒChinese (Traditional)”…””}”hh2sbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ,/translations/zh_TW/admin-guide/hw-vuln/srso”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒItalian”…””}”hhFsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ,/translations/it_IT/admin-guide/hw-vuln/srso”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒJapanese”…””}”hhZsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ,/translations/ja_JP/admin-guide/hw-vuln/srso”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒKorean”…””}”hhnsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ,/translations/ko_KR/admin-guide/hw-vuln/srso”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒPortuguese (Brazilian)”…””}”hh‚sbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ,/translations/pt_BR/admin-guide/hw-vuln/srso”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒSpanish”…””}”hh–sbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ,/translations/sp_SP/admin-guide/hw-vuln/srso”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubeh}”(h]”h ]”h"]”h$]”h&]”Œcurrent_language”ŒEnglish”uh1h
hhŒ	_document”hŒsource”NŒline”NubhŒcomment”“”)”}”(hŒ SPDX-License-Identifier: GPL-2.0”h]”hŒ SPDX-License-Identifier: GPL-2.0”…””}”hh·sbah}”(h]”h ]”h"]”h$]”h&]”Œ	xml:space”Œpreserve”uh1hµhhh²hh³ŒF/var/lib/git/docbuild/linux/Documentation/admin-guide/hw-vuln/srso.rst”h´KubhŒsection”“”)”}”(hhh]”(hŒtitle”“”)”}”(hŒ(Speculative Return Stack Overflow (SRSO)”h]”hŒ(Speculative Return Stack Overflow (SRSO)”…””}”(hhÏh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhhÊh²hh³hÇh´KubhŒ	paragraph”“”)”}”(hXk  This is a mitigation for the speculative return stack overflow (SRSO)
vulnerability found on AMD processors. The mechanism is by now the well
known scenario of poisoning CPU functional units - the Branch Target
Buffer (BTB) and Return Address Predictor (RAP) in this case - and then
tricking the elevated privilege domain (the kernel) into leaking
sensitive data.”h]”hXk  This is a mitigation for the speculative return stack overflow (SRSO)
vulnerability found on AMD processors. The mechanism is by now the well
known scenario of poisoning CPU functional units - the Branch Target
Buffer (BTB) and Return Address Predictor (RAP) in this case - and then
tricking the elevated privilege domain (the kernel) into leaking
sensitive data.”…””}”(hhßh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´KhhÊh²hubhÞ)”}”(hXW  AMD CPUs predict RET instructions using a Return Address Predictor (aka
Return Address Stack/Return Stack Buffer). In some cases, a non-architectural
CALL instruction (i.e., an instruction predicted to be a CALL but is
not actually a CALL) can create an entry in the RAP which may be used
to predict the target of a subsequent RET instruction.”h]”hXW  AMD CPUs predict RET instructions using a Return Address Predictor (aka
Return Address Stack/Return Stack Buffer). In some cases, a non-architectural
CALL instruction (i.e., an instruction predicted to be a CALL but is
not actually a CALL) can create an entry in the RAP which may be used
to predict the target of a subsequent RET instruction.”…””}”(hhíh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´KhhÊh²hubhÞ)”}”(hX^  The specific circumstances that lead to this varies by microarchitecture
but the concern is that an attacker can mis-train the CPU BTB to predict
non-architectural CALL instructions in kernel space and use this to
control the speculative target of a subsequent kernel RET, potentially
leading to information disclosure via a speculative side-channel.”h]”hX^  The specific circumstances that lead to this varies by microarchitecture
but the concern is that an attacker can mis-train the CPU BTB to predict
non-architectural CALL instructions in kernel space and use this to
control the speculative target of a subsequent kernel RET, potentially
leading to information disclosure via a speculative side-channel.”…””}”(hhûh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´KhhÊh²hubhÞ)”}”(hŒ*The issue is tracked under CVE-2023-20569.”h]”hŒ*The issue is tracked under CVE-2023-20569.”…””}”(hj	  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´KhhÊh²hubhÉ)”}”(hhh]”(hÎ)”}”(hŒAffected processors”h]”hŒAffected processors”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhj  h²hh³hÇh´KubhÞ)”}”(hŒkAMD Zen, generations 1-4. That is, all families 0x17 and 0x19. Older
processors have not been investigated.”h]”hŒkAMD Zen, generations 1-4. That is, all families 0x17 and 0x19. Older
processors have not been investigated.”…””}”(hj(  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´Khj  h²hubeh}”(h]”Œaffected-processors”ah ]”h"]”Œaffected processors”ah$]”h&]”uh1hÈhhÊh²hh³hÇh´KubhÉ)”}”(hhh]”(hÎ)”}”(hŒSystem information and options”h]”hŒSystem information and options”…””}”(hjA  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhj>  h²hh³hÇh´K"ubhÞ)”}”(hŒaFirst of all, it is required that the latest microcode be loaded for
mitigations to be effective.”h]”hŒaFirst of all, it is required that the latest microcode be loaded for
mitigations to be effective.”…””}”(hjO  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K$hj>  h²hubhÞ)”}”(hŒ1The sysfs file showing SRSO mitigation status is:”h]”hŒ1The sysfs file showing SRSO mitigation status is:”…””}”(hj]  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K'hj>  h²hubhŒblock_quote”“”)”}”(hŒ=/sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow
”h]”hÞ)”}”(hŒ</sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow”h]”hŒ</sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow”…””}”(hjq  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K)hjm  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  h³hÇh´K)hj>  h²hubhÞ)”}”(hŒ%The possible values in this file are:”h]”hŒ%The possible values in this file are:”…””}”(hj…  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K+hj>  h²hubjl  )”}”(hŒ5* 'Not affected':

  The processor is not vulnerable
”h]”hŒbullet_list”“”)”}”(hhh]”hŒ	list_item”“”)”}”(hŒ1'Not affected':

The processor is not vulnerable
”h]”(hÞ)”}”(hŒ'Not affected':”h]”hŒâ€˜Not affectedâ€™:”…””}”(hj¢  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K-hjž  ubhÞ)”}”(hŒThe processor is not vulnerable”h]”hŒThe processor is not vulnerable”…””}”(hj°  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K/hjž  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jœ  hj™  ubah}”(h]”h ]”h"]”h$]”h&]”Œbullet”Œ*”uh1j—  h³hÇh´K-hj“  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  h³hÇh´K-hj>  h²hubj˜  )”}”(hhh]”j  )”}”(hŒR'Vulnerable':

 The processor is vulnerable and no mitigations have been applied.
”h]”(hÞ)”}”(hŒ'Vulnerable':”h]”hŒâ€˜Vulnerableâ€™:”…””}”(hjÙ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K1hjÕ  ubjl  )”}”(hŒBThe processor is vulnerable and no mitigations have been applied.
”h]”hÞ)”}”(hŒAThe processor is vulnerable and no mitigations have been applied.”h]”hŒAThe processor is vulnerable and no mitigations have been applied.”…””}”(hjë  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K3hjç  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  h³hÇh´K3hjÕ  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jœ  hjÒ  h²hh³hÇh´Nubah}”(h]”h ]”h"]”h$]”h&]”jÊ  jË  uh1j—  h³hÇh´K1hj>  h²hubjl  )”}”(hX?	  * 'Vulnerable: No microcode':

  The processor is vulnerable, no microcode extending IBPB
  functionality to address the vulnerability has been applied.

* 'Vulnerable: Safe RET, no microcode':

  The "Safe RET" mitigation (see below) has been applied to protect the
  kernel, but the IBPB-extending microcode has not been applied.  User
  space tasks may still be vulnerable.

* 'Vulnerable: Microcode, no safe RET':

  Extended IBPB functionality microcode patch has been applied. It does
  not address User->Kernel and Guest->Host transitions protection but it
  does address User->User and VM->VM attack vectors.

  Note that User->User mitigation is controlled by how the IBPB aspect in
  the Spectre v2 mitigation is selected:

   * conditional IBPB:

     where each process can select whether it needs an IBPB issued
     around it PR_SPEC_DISABLE/_ENABLE etc, see :doc:`spectre`

   * strict:

     i.e., always on - by supplying spectre_v2_user=on on the kernel
     command line

  (spec_rstack_overflow=microcode)

* 'Mitigation: Safe RET':

  Combined microcode/software mitigation. It complements the
  extended IBPB microcode patch functionality by addressing
  User->Kernel and Guest->Host transitions protection.

  Selected by default or by spec_rstack_overflow=safe-ret

* 'Mitigation: IBPB':

  Similar protection as "safe RET" above but employs an IBPB barrier on
  privilege domain crossings (User->Kernel, Guest->Host).

 (spec_rstack_overflow=ibpb)

* 'Mitigation: IBPB on VMEXIT':

  Mitigation addressing the cloud provider scenario - the Guest->Host
  transitions only.

  (spec_rstack_overflow=ibpb-vmexit)

* 'Mitigation: Reduced Speculation':

  This mitigation gets automatically enabled when the above one "IBPB on
  VMEXIT" has been selected and the CPU supports the BpSpecReduce bit.

  It gets automatically enabled on machines which have the
  SRSO_USER_KERNEL_NO=1 CPUID bit. In that case, the code logic is to switch
  to the above =ibpb-vmexit mitigation because the user/kernel boundary is
  not affected anymore and thus "safe RET" is not needed.

  After enabling the IBPB on VMEXIT mitigation option, the BpSpecReduce bit
  is detected (functionality present on all such machines) and that
  practically overrides IBPB on VMEXIT as it has a lot less performance
  impact and takes care of the guest->host attack vector too.
”h]”(j˜  )”}”(hhh]”(j  )”}”(hŒ“'Vulnerable: No microcode':

The processor is vulnerable, no microcode extending IBPB
functionality to address the vulnerability has been applied.
”h]”(hÞ)”}”(hŒ'Vulnerable: No microcode':”h]”hŒâ€˜Vulnerable: No microcodeâ€™:”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K5hj  ubhÞ)”}”(hŒuThe processor is vulnerable, no microcode extending IBPB
functionality to address the vulnerability has been applied.”h]”hŒuThe processor is vulnerable, no microcode extending IBPB
functionality to address the vulnerability has been applied.”…””}”(hj$  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K7hj  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jœ  hj  ubj  )”}”(hŒ×'Vulnerable: Safe RET, no microcode':

The "Safe RET" mitigation (see below) has been applied to protect the
kernel, but the IBPB-extending microcode has not been applied.  User
space tasks may still be vulnerable.
”h]”(hÞ)”}”(hŒ%'Vulnerable: Safe RET, no microcode':”h]”hŒ)â€˜Vulnerable: Safe RET, no microcodeâ€™:”…””}”(hj<  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K:hj8  ubhÞ)”}”(hŒ¯The "Safe RET" mitigation (see below) has been applied to protect the
kernel, but the IBPB-extending microcode has not been applied.  User
space tasks may still be vulnerable.”h]”hŒ³The â€œSafe RETâ€ mitigation (see below) has been applied to protect the
kernel, but the IBPB-extending microcode has not been applied.  User
space tasks may still be vulnerable.”…””}”(hjJ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K<hj8  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jœ  hj  ubj  )”}”(hXn  'Vulnerable: Microcode, no safe RET':

Extended IBPB functionality microcode patch has been applied. It does
not address User->Kernel and Guest->Host transitions protection but it
does address User->User and VM->VM attack vectors.

Note that User->User mitigation is controlled by how the IBPB aspect in
the Spectre v2 mitigation is selected:

 * conditional IBPB:

   where each process can select whether it needs an IBPB issued
   around it PR_SPEC_DISABLE/_ENABLE etc, see :doc:`spectre`

 * strict:

   i.e., always on - by supplying spectre_v2_user=on on the kernel
   command line

(spec_rstack_overflow=microcode)
”h]”(hÞ)”}”(hŒ%'Vulnerable: Microcode, no safe RET':”h]”hŒ)â€˜Vulnerable: Microcode, no safe RETâ€™:”…””}”(hjb  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K@hj^  ubhÞ)”}”(hŒ¿Extended IBPB functionality microcode patch has been applied. It does
not address User->Kernel and Guest->Host transitions protection but it
does address User->User and VM->VM attack vectors.”h]”hŒ¿Extended IBPB functionality microcode patch has been applied. It does
not address User->Kernel and Guest->Host transitions protection but it
does address User->User and VM->VM attack vectors.”…””}”(hjp  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´KBhj^  ubhÞ)”}”(hŒnNote that User->User mitigation is controlled by how the IBPB aspect in
the Spectre v2 mitigation is selected:”h]”hŒnNote that User->User mitigation is controlled by how the IBPB aspect in
the Spectre v2 mitigation is selected:”…””}”(hj~  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´KFhj^  ubjl  )”}”(hŒî* conditional IBPB:

  where each process can select whether it needs an IBPB issued
  around it PR_SPEC_DISABLE/_ENABLE etc, see :doc:`spectre`

* strict:

  i.e., always on - by supplying spectre_v2_user=on on the kernel
  command line
”h]”j˜  )”}”(hhh]”(j  )”}”(hŒ‹conditional IBPB:

where each process can select whether it needs an IBPB issued
around it PR_SPEC_DISABLE/_ENABLE etc, see :doc:`spectre`
”h]”(hÞ)”}”(hŒconditional IBPB:”h]”hŒconditional IBPB:”…””}”(hj—  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´KIhj“  ubhÞ)”}”(hŒwwhere each process can select whether it needs an IBPB issued
around it PR_SPEC_DISABLE/_ENABLE etc, see :doc:`spectre`”h]”(hŒiwhere each process can select whether it needs an IBPB issued
around it PR_SPEC_DISABLE/_ENABLE etc, see ”…””}”(hj¥  h²hh³Nh´Nubh)”}”(hŒ:doc:`spectre`”h]”hŒinline”“”)”}”(hj¯  h]”hŒspectre”…””}”(hj³  h²hh³Nh´Nubah}”(h]”h ]”(Œxref”Œstd”Œstd-doc”eh"]”h$]”h&]”uh1j±  hj­  ubah}”(h]”h ]”h"]”h$]”h&]”Œrefdoc”Œadmin-guide/hw-vuln/srso”Œ	refdomain”j¾  Œreftype”Œdoc”Œrefexplicit”‰Œrefwarn”ˆŒ	reftarget”Œspectre”uh1hh³hÇh´KKhj¥  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´KKhj“  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jœ  hj  ubj  )”}”(hŒVstrict:

i.e., always on - by supplying spectre_v2_user=on on the kernel
command line
”h]”(hÞ)”}”(hŒstrict:”h]”hŒstrict:”…””}”(hjâ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´KNhjÞ  ubhÞ)”}”(hŒLi.e., always on - by supplying spectre_v2_user=on on the kernel
command line”h]”hŒLi.e., always on - by supplying spectre_v2_user=on on the kernel
command line”…””}”(hjð  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´KPhjÞ  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jœ  hj  ubeh}”(h]”h ]”h"]”h$]”h&]”jÊ  jË  uh1j—  h³hÇh´KIhjŒ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  h³hÇh´KIhj^  ubhÞ)”}”(hŒ (spec_rstack_overflow=microcode)”h]”hŒ (spec_rstack_overflow=microcode)”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´KShj^  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jœ  hj  ubj  )”}”(hŒü'Mitigation: Safe RET':

Combined microcode/software mitigation. It complements the
extended IBPB microcode patch functionality by addressing
User->Kernel and Guest->Host transitions protection.

Selected by default or by spec_rstack_overflow=safe-ret
”h]”(hÞ)”}”(hŒ'Mitigation: Safe RET':”h]”hŒâ€˜Mitigation: Safe RETâ€™:”…””}”(hj(  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´KUhj$  ubhÞ)”}”(hŒ©Combined microcode/software mitigation. It complements the
extended IBPB microcode patch functionality by addressing
User->Kernel and Guest->Host transitions protection.”h]”hŒ©Combined microcode/software mitigation. It complements the
extended IBPB microcode patch functionality by addressing
User->Kernel and Guest->Host transitions protection.”…””}”(hj6  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´KWhj$  ubhÞ)”}”(hŒ7Selected by default or by spec_rstack_overflow=safe-ret”h]”hŒ7Selected by default or by spec_rstack_overflow=safe-ret”…””}”(hjD  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K[hj$  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jœ  hj  ubj  )”}”(hŒ“'Mitigation: IBPB':

Similar protection as "safe RET" above but employs an IBPB barrier on
privilege domain crossings (User->Kernel, Guest->Host).
”h]”(hÞ)”}”(hŒ'Mitigation: IBPB':”h]”hŒâ€˜Mitigation: IBPBâ€™:”…””}”(hj\  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K]hjX  ubhÞ)”}”(hŒ}Similar protection as "safe RET" above but employs an IBPB barrier on
privilege domain crossings (User->Kernel, Guest->Host).”h]”hŒSimilar protection as â€œsafe RETâ€ above but employs an IBPB barrier on
privilege domain crossings (User->Kernel, Guest->Host).”…””}”(hjj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K_hjX  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jœ  hj  ubeh}”(h]”h ]”h"]”h$]”h&]”jÊ  jË  uh1j—  h³hÇh´K5hj  ubjl  )”}”(hŒ(spec_rstack_overflow=ibpb)
”h]”hÞ)”}”(hŒ(spec_rstack_overflow=ibpb)”h]”hŒ(spec_rstack_overflow=ibpb)”…””}”(hjˆ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´Kbhj„  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  h³hÇh´Kbhj  ubj˜  )”}”(hhh]”(j  )”}”(hŒ™'Mitigation: IBPB on VMEXIT':

Mitigation addressing the cloud provider scenario - the Guest->Host
transitions only.

(spec_rstack_overflow=ibpb-vmexit)
”h]”(hÞ)”}”(hŒ'Mitigation: IBPB on VMEXIT':”h]”hŒ!â€˜Mitigation: IBPB on VMEXITâ€™:”…””}”(hj£  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´KdhjŸ  ubhÞ)”}”(hŒUMitigation addressing the cloud provider scenario - the Guest->Host
transitions only.”h]”hŒUMitigation addressing the cloud provider scenario - the Guest->Host
transitions only.”…””}”(hj±  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´KfhjŸ  ubhÞ)”}”(hŒ"(spec_rstack_overflow=ibpb-vmexit)”h]”hŒ"(spec_rstack_overflow=ibpb-vmexit)”…””}”(hj¿  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´KihjŸ  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jœ  hjœ  ubj  )”}”(hXÅ  'Mitigation: Reduced Speculation':

This mitigation gets automatically enabled when the above one "IBPB on
VMEXIT" has been selected and the CPU supports the BpSpecReduce bit.

It gets automatically enabled on machines which have the
SRSO_USER_KERNEL_NO=1 CPUID bit. In that case, the code logic is to switch
to the above =ibpb-vmexit mitigation because the user/kernel boundary is
not affected anymore and thus "safe RET" is not needed.

After enabling the IBPB on VMEXIT mitigation option, the BpSpecReduce bit
is detected (functionality present on all such machines) and that
practically overrides IBPB on VMEXIT as it has a lot less performance
impact and takes care of the guest->host attack vector too.
”h]”(hÞ)”}”(hŒ"'Mitigation: Reduced Speculation':”h]”hŒ&â€˜Mitigation: Reduced Speculationâ€™:”…””}”(hj×  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´KkhjÓ  ubhÞ)”}”(hŒ‹This mitigation gets automatically enabled when the above one "IBPB on
VMEXIT" has been selected and the CPU supports the BpSpecReduce bit.”h]”hŒThis mitigation gets automatically enabled when the above one â€œIBPB on
VMEXITâ€ has been selected and the CPU supports the BpSpecReduce bit.”…””}”(hjå  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´KmhjÓ  ubhÞ)”}”(hX  It gets automatically enabled on machines which have the
SRSO_USER_KERNEL_NO=1 CPUID bit. In that case, the code logic is to switch
to the above =ibpb-vmexit mitigation because the user/kernel boundary is
not affected anymore and thus "safe RET" is not needed.”h]”hX  It gets automatically enabled on machines which have the
SRSO_USER_KERNEL_NO=1 CPUID bit. In that case, the code logic is to switch
to the above =ibpb-vmexit mitigation because the user/kernel boundary is
not affected anymore and thus â€œsafe RETâ€ is not needed.”…””}”(hjó  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´KphjÓ  ubhÞ)”}”(hX  After enabling the IBPB on VMEXIT mitigation option, the BpSpecReduce bit
is detected (functionality present on all such machines) and that
practically overrides IBPB on VMEXIT as it has a lot less performance
impact and takes care of the guest->host attack vector too.”h]”hX  After enabling the IBPB on VMEXIT mitigation option, the BpSpecReduce bit
is detected (functionality present on all such machines) and that
practically overrides IBPB on VMEXIT as it has a lot less performance
impact and takes care of the guest->host attack vector too.”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´KuhjÓ  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jœ  hjœ  ubeh}”(h]”h ]”h"]”h$]”h&]”jÊ  jË  uh1j—  h³hÇh´Kdhj  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jk  h³hÇh´K5hj>  h²hubhÞ)”}”(hŒ8In order to exploit vulnerability, an attacker needs to:”h]”hŒ8In order to exploit vulnerability, an attacker needs to:”…””}”(hj!  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´Kzhj>  h²hubjl  )”}”(hX  - gain local access on the machine

- break kASLR

- find gadgets in the running kernel in order to use them in the exploit

- potentially create and pin an additional workload on the sibling
  thread, depending on the microarchitecture (not necessary on fam 0x19)

- run the exploit
”h]”j˜  )”}”(hhh]”(j  )”}”(hŒ!gain local access on the machine
”h]”hÞ)”}”(hŒ gain local access on the machine”h]”hŒ gain local access on the machine”…””}”(hj:  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K|hj6  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jœ  hj3  ubj  )”}”(hŒbreak kASLR
”h]”hÞ)”}”(hŒbreak kASLR”h]”hŒbreak kASLR”…””}”(hjR  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K~hjN  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jœ  hj3  ubj  )”}”(hŒGfind gadgets in the running kernel in order to use them in the exploit
”h]”hÞ)”}”(hŒFfind gadgets in the running kernel in order to use them in the exploit”h]”hŒFfind gadgets in the running kernel in order to use them in the exploit”…””}”(hjj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K€hjf  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jœ  hj3  ubj  )”}”(hŒˆpotentially create and pin an additional workload on the sibling
thread, depending on the microarchitecture (not necessary on fam 0x19)
”h]”hÞ)”}”(hŒ‡potentially create and pin an additional workload on the sibling
thread, depending on the microarchitecture (not necessary on fam 0x19)”h]”hŒ‡potentially create and pin an additional workload on the sibling
thread, depending on the microarchitecture (not necessary on fam 0x19)”…””}”(hj‚  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K‚hj~  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jœ  hj3  ubj  )”}”(hŒrun the exploit
”h]”hÞ)”}”(hŒrun the exploit”h]”hŒrun the exploit”…””}”(hjš  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K…hj–  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jœ  hj3  ubeh}”(h]”h ]”h"]”h$]”h&]”jÊ  Œ-”uh1j—  h³hÇh´K|hj/  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  h³hÇh´K|hj>  h²hubhÞ)”}”(hŒÀConsidering the performance implications of each mitigation type, the
default one is 'Mitigation: safe RET' which should take care of most
attack vectors, including the local User->Kernel one.”h]”hŒÄConsidering the performance implications of each mitigation type, the
default one is â€˜Mitigation: safe RETâ€™ which should take care of most
attack vectors, including the local User->Kernel one.”…””}”(hj»  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K‡hj>  h²hubhÞ)”}”(hŒhAs always, the user is advised to keep her/his system up-to-date by
applying software updates regularly.”h]”hŒhAs always, the user is advised to keep her/his system up-to-date by
applying software updates regularly.”…””}”(hjÉ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K‹hj>  h²hubhÞ)”}”(hŒbThe default setting will be reevaluated when needed and especially when
new attack vectors appear.”h]”hŒbThe default setting will be reevaluated when needed and especially when
new attack vectors appear.”…””}”(hj×  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´KŽhj>  h²hubhÞ)”}”(hX  As one can surmise, 'Mitigation: safe RET' does come at the cost of some
performance depending on the workload. If one trusts her/his userspace
and does not want to suffer the performance impact, one can always
disable the mitigation with spec_rstack_overflow=off.”h]”hX  As one can surmise, â€˜Mitigation: safe RETâ€™ does come at the cost of some
performance depending on the workload. If one trusts her/his userspace
and does not want to suffer the performance impact, one can always
disable the mitigation with spec_rstack_overflow=off.”…””}”(hjå  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K‘hj>  h²hubhÞ)”}”(hŒãSimilarly, 'Mitigation: IBPB' is another full mitigation type employing
an indirect branch prediction barrier after having applied the required
microcode patch for one's system. This mitigation comes also at
a performance cost.”h]”hŒéSimilarly, â€˜Mitigation: IBPBâ€™ is another full mitigation type employing
an indirect branch prediction barrier after having applied the required
microcode patch for oneâ€™s system. This mitigation comes also at
a performance cost.”…””}”(hjó  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K–hj>  h²hubeh}”(h]”Œsystem-information-and-options”ah ]”h"]”Œsystem information and options”ah$]”h&]”uh1hÈhhÊh²hh³hÇh´K"ubhÉ)”}”(hhh]”(hÎ)”}”(hŒMitigation: Safe RET”h]”hŒMitigation: Safe RET”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhj	  h²hh³hÇh´KœubhÞ)”}”(hX  The mitigation works by ensuring all RET instructions speculate to
a controlled location, similar to how speculation is controlled in the
retpoline sequence.  To accomplish this, the __x86_return_thunk forces
the CPU to mispredict every function return using a 'safe return'
sequence.”h]”hX   The mitigation works by ensuring all RET instructions speculate to
a controlled location, similar to how speculation is controlled in the
retpoline sequence.  To accomplish this, the __x86_return_thunk forces
the CPU to mispredict every function return using a â€˜safe returnâ€™
sequence.”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´Kžhj	  h²hubhÞ)”}”(hX¡  To ensure the safety of this mitigation, the kernel must ensure that the
safe return sequence is itself free from attacker interference.  In Zen3
and Zen4, this is accomplished by creating a BTB alias between the
untraining function srso_alias_untrain_ret() and the safe return
function srso_alias_safe_ret() which results in evicting a potentially
poisoned BTB entry and using that safe one for all function returns.”h]”hX¡  To ensure the safety of this mitigation, the kernel must ensure that the
safe return sequence is itself free from attacker interference.  In Zen3
and Zen4, this is accomplished by creating a BTB alias between the
untraining function srso_alias_untrain_ret() and the safe return
function srso_alias_safe_ret() which results in evicting a potentially
poisoned BTB entry and using that safe one for all function returns.”…””}”(hj(  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K¤hj	  h²hubhÞ)”}”(hŒIn older Zen1 and Zen2, this is accomplished using a reinterpretation
technique similar to Retbleed one: srso_untrain_ret() and
srso_safe_ret().”h]”hŒIn older Zen1 and Zen2, this is accomplished using a reinterpretation
technique similar to Retbleed one: srso_untrain_ret() and
srso_safe_ret().”…””}”(hj6  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K«hj	  h²hubeh}”(h]”Œmitigation-safe-ret”ah ]”h"]”Œmitigation: safe ret”ah$]”h&]”uh1hÈhhÊh²hh³hÇh´KœubhÉ)”}”(hhh]”(hÎ)”}”(hŒ/Checking the safe RET mitigation actually works”h]”hŒ/Checking the safe RET mitigation actually works”…””}”(hjO  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhjL  h²hh³hÇh´K°ubhÞ)”}”(hŒ|In case one wants to validate whether the SRSO safe RET mitigation works
on a kernel, one could use two performance counters”h]”hŒ|In case one wants to validate whether the SRSO safe RET mitigation works
on a kernel, one could use two performance counters”…””}”(hj]  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K²hjL  h²hubj˜  )”}”(hhh]”(j  )”}”(hŒ&PMC_0xc8 - Count of RET/RET lw retired”h]”hÞ)”}”(hjp  h]”hŒ&PMC_0xc8 - Count of RET/RET lw retired”…””}”(hjr  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´Kµhjn  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jœ  hjk  h²hh³hÇh´Nubj  )”}”(hŒ4PMC_0xc9 - Count of RET/RET lw retired mispredicted
”h]”hÞ)”}”(hŒ3PMC_0xc9 - Count of RET/RET lw retired mispredicted”h]”hŒ3PMC_0xc9 - Count of RET/RET lw retired mispredicted”…””}”(hj‰  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K¶hj…  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jœ  hjk  h²hh³hÇh´Nubeh}”(h]”h ]”h"]”h$]”h&]”jÊ  jË  uh1j—  h³hÇh´KµhjL  h²hubhÞ)”}”(hŒŠand compare the number of RETs retired properly vs those retired
mispredicted, in kernel mode. Another way of specifying those events
is::”h]”hŒ‰and compare the number of RETs retired properly vs those retired
mispredicted, in kernel mode. Another way of specifying those events
is:”…””}”(hj£  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K¸hjL  h²hubhŒliteral_block”“”)”}”(hŒÍ# perf list ex_ret_near_ret

List of pre-defined events (to be used in -e or -M):

core:
  ex_ret_near_ret
       [Retired Near Returns]
  ex_ret_near_ret_mispred
       [Retired Near Returns Mispredicted]”h]”hŒÍ# perf list ex_ret_near_ret

List of pre-defined events (to be used in -e or -M):

core:
  ex_ret_near_ret
       [Retired Near Returns]
  ex_ret_near_ret_mispred
       [Retired Near Returns Mispredicted]”…””}”hj³  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j±  h³hÇh´K¼hjL  h²hubhÞ)”}”(hŒ.Either the command using the event mnemonics::”h]”hŒ-Either the command using the event mnemonics:”…””}”(hjÁ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´KÆhjL  h²hubj²  )”}”(hŒG# perf stat -e ex_ret_near_ret:k -e ex_ret_near_ret_mispred:k sleep 10s”h]”hŒG# perf stat -e ex_ret_near_ret:k -e ex_ret_near_ret_mispred:k sleep 10s”…””}”hjÏ  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j±  h³hÇh´KÈhjL  h²hubhÞ)”}”(hŒor using the raw PMC numbers::”h]”hŒor using the raw PMC numbers:”…””}”(hjÝ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´KÊhjL  h²hubj²  )”}”(hŒM# perf stat -e cpu/event=0xc8,umask=0/k -e cpu/event=0xc9,umask=0/k sleep 10s”h]”hŒM# perf stat -e cpu/event=0xc8,umask=0/k -e cpu/event=0xc9,umask=0/k sleep 10s”…””}”hjë  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j±  h³hÇh´KÌhjL  h²hubhÞ)”}”(hŒMshould give the same amount. I.e., every RET retired should be
mispredicted::”h]”hŒLshould give the same amount. I.e., every RET retired should be
mispredicted:”…””}”(hjù  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´KÎhjL  h²hubj²  )”}”(hXn  [root@brent: ~/kernel/linux/tools/perf> ./perf stat -e cpu/event=0xc8,umask=0/k -e cpu/event=0xc9,umask=0/k sleep 10s

 Performance counter stats for 'sleep 10s':

           137,167      cpu/event=0xc8,umask=0/k
           137,173      cpu/event=0xc9,umask=0/k

      10.004110303 seconds time elapsed

       0.000000000 seconds user
       0.004462000 seconds sys”h]”hXn  [root@brent: ~/kernel/linux/tools/perf> ./perf stat -e cpu/event=0xc8,umask=0/k -e cpu/event=0xc9,umask=0/k sleep 10s

 Performance counter stats for 'sleep 10s':

           137,167      cpu/event=0xc8,umask=0/k
           137,173      cpu/event=0xc9,umask=0/k

      10.004110303 seconds time elapsed

       0.000000000 seconds user
       0.004462000 seconds sys”…””}”hj  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j±  h³hÇh´KÑhjL  h²hubhÞ)”}”(hŒÞvs the case when the mitigation is disabled (spec_rstack_overflow=off)
or not functioning properly, showing usually a lot smaller number of
mispredicted retired RETs vs the overall count of retired RETs during
a workload::”h]”hŒÝvs the case when the mitigation is disabled (spec_rstack_overflow=off)
or not functioning properly, showing usually a lot smaller number of
mispredicted retired RETs vs the overall count of retired RETs during
a workload:”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´KÝhjL  h²hubj²  )”}”(hXn  [root@brent: ~/kernel/linux/tools/perf> ./perf stat -e cpu/event=0xc8,umask=0/k -e cpu/event=0xc9,umask=0/k sleep 10s

 Performance counter stats for 'sleep 10s':

           201,627      cpu/event=0xc8,umask=0/k
             4,074      cpu/event=0xc9,umask=0/k

      10.003267252 seconds time elapsed

       0.002729000 seconds user
       0.000000000 seconds sys”h]”hXn  [root@brent: ~/kernel/linux/tools/perf> ./perf stat -e cpu/event=0xc8,umask=0/k -e cpu/event=0xc9,umask=0/k sleep 10s

 Performance counter stats for 'sleep 10s':

           201,627      cpu/event=0xc8,umask=0/k
             4,074      cpu/event=0xc9,umask=0/k

      10.003267252 seconds time elapsed

       0.002729000 seconds user
       0.000000000 seconds sys”…””}”hj#  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j±  h³hÇh´KâhjL  h²hubhÞ)”}”(hŒ_Also, there is a selftest which performs the above, go to
tools/testing/selftests/x86/ and do::”h]”hŒ^Also, there is a selftest which performs the above, go to
tools/testing/selftests/x86/ and do:”…””}”(hj1  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´KîhjL  h²hubj²  )”}”(hŒmake srso
./srso”h]”hŒmake srso
./srso”…””}”hj?  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j±  h³hÇh´KñhjL  h²hubeh}”(h]”Œ/checking-the-safe-ret-mitigation-actually-works”ah ]”h"]”Œ/checking the safe ret mitigation actually works”ah$]”h&]”uh1hÈhhÊh²hh³hÇh´K°ubeh}”(h]”Œ&speculative-return-stack-overflow-srso”ah ]”h"]”Œ(speculative return stack overflow (srso)”ah$]”h&]”uh1hÈhhh²hh³hÇh´Kubeh}”(h]”h ]”h"]”h$]”h&]”Œsource”hÇuh1hŒcurrent_source”NŒcurrent_line”NŒsettings”Œdocutils.frontend”ŒValues”“”)”}”(hÍNŒ	generator”NŒ	datestamp”NŒsource_link”NŒ
source_url”NŒtoc_backlinks”Œentry”Œfootnote_backlinks”KŒsectnum_xform”KŒstrip_comments”NŒstrip_elements_with_classes”NŒstrip_classes”NŒreport_level”KŒ
halt_level”KŒexit_status_level”KŒdebug”NŒwarning_stream”NŒ	traceback”ˆŒinput_encoding”Œ	utf-8-sig”Œinput_encoding_error_handler”Œstrict”Œoutput_encoding”Œutf-8”Œoutput_encoding_error_handler”j€  Œerror_encoding”Œutf-8”Œerror_encoding_error_handler”Œbackslashreplace”Œlanguage_code”Œen”Œrecord_dependencies”NŒconfig”NŒ	id_prefix”hŒauto_id_prefix”Œid”Œdump_settings”NŒdump_internals”NŒdump_transforms”NŒdump_pseudo_xml”NŒexpose_internals”NŒstrict_visitor”NŒ_disable_config”NŒ_source”hÇŒ_destination”NŒ_config_files”]”Œ7/var/lib/git/docbuild/linux/Documentation/docutils.conf”aŒfile_insertion_enabled”ˆŒraw_enabled”KŒline_length_limit”M'Œpep_references”NŒpep_base_url”Œhttps://peps.python.org/”Œpep_file_url_template”Œpep-%04d”Œrfc_references”NŒrfc_base_url”Œ&https://datatracker.ietf.org/doc/html/”Œ	tab_width”KŒtrim_footnote_reference_space”‰Œsyntax_highlight”Œlong”Œsmart_quotes”ˆŒsmartquotes_locales”]”Œcharacter_level_inline_markup”‰Œdoctitle_xform”‰Œdocinfo_xform”KŒsectsubtitle_xform”‰Œimage_loading”Œlink”Œembed_stylesheet”‰Œcloak_email_addresses”ˆŒsection_self_link”‰Œenv”NubŒreporter”NŒindirect_targets”]”Œsubstitution_defs”}”Œsubstitution_names”}”Œrefnames”}”Œrefids”}”Œnameids”}”(jZ  jW  j;  j8  j  j  jI  jF  jR  jO  uŒ	nametypes”}”(jZ  ‰j;  ‰j  ‰jI  ‰jR  ‰uh}”(jW  hÊj8  j  j  j>  jF  j	  jO  jL  uŒfootnote_refs”}”Œcitation_refs”}”Œautofootnotes”]”Œautofootnote_refs”]”Œsymbol_footnotes”]”Œsymbol_footnote_refs”]”Œ	footnotes”]”Œ	citations”]”Œautofootnote_start”KŒsymbol_footnote_start”K Œ
id_counter”Œcollections”ŒCounter”“”}”…”R”Œparse_messages”]”Œtransform_messages”]”Œtransformer”NŒinclude_log”]”Œ
decoration”Nh²hub.