Commit 09f9f37c authored by Borislav Petkov (AMD)'s avatar Borislav Petkov (AMD)
Browse files

Documentation/srso: Document IBPB aspect and fix formatting 



Add a note about the dependency of the User->User mitigation on the
previous Spectre v2 IBPB selection.

Make the layout moar pretty.

Signed-off-by: default avatarBorislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20230809102700.29449-4-bp@alien8.de
parent 0fddfe33

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

+44 −27
Original line number Diff line number Diff line
@@ -42,43 +42,60 @@ The sysfs file showing SRSO mitigation status is: 


The possible values in this file are:



 - 'Not affected'               The processor is not vulnerable

 * 'Not affected':



 - 'Vulnerable: no microcode'   The processor is vulnerable, no

                                microcode extending IBPB functionality

                                to address the vulnerability has been

                                applied.

   The processor is not vulnerable



 - 'Mitigation: microcode'      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.

 * 'Vulnerable: no microcode':



   The processor is vulnerable, no microcode extending IBPB

   functionality to address the vulnerability has been applied.



 * 'Mitigation: microcode':



   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'       Software-only mitigation. It complements

                                the extended IBPB microcode patch

                                functionality by addressing User->Kernel 

                                and Guest->Host transitions protection.

 * 'Mitigation: safe RET':



   Software-only 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



                                Selected by default or by

                                spec_rstack_overflow=safe-ret

 * 'Mitigation: IBPB':



 - 'Mitigation: IBPB'           Similar protection as "safe RET" above

                                but employs an IBPB barrier on privilege

                                domain crossings (User->Kernel,

                                Guest->Host).

   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.

 * 'Mitigation: IBPB on VMEXIT':



   Mitigation addressing the cloud provider scenario - the Guest->Host

   transitions only.



   (spec_rstack_overflow=ibpb-vmexit)







In order to exploit vulnerability, an attacker needs to:



 - gain local access on the machine