Skip to content

Commit

Permalink
Documentation/srso: Document IBPB aspect and fix formatting
Browse files Browse the repository at this point in the history
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: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20230809102700.29449-4-bp@alien8.de
  • Loading branch information
Borislav Petkov (AMD) committed Aug 10, 2023
1 parent 0fddfe3 commit 09f9f37
Showing 1 changed file with 44 additions and 27 deletions.
71 changes: 44 additions & 27 deletions Documentation/admin-guide/hw-vuln/srso.rst
Original file line number Diff line number Diff line change
Expand Up @@ -42,42 +42,59 @@ 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':

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

- 'Mitigation: safe RET' Software-only mitigation. It complements
the extended IBPB microcode patch
functionality by addressing User->Kernel
and Guest->Host transitions protection.
* 'Mitigation: microcode':

Selected by default or by
spec_rstack_overflow=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.

- 'Mitigation: IBPB' Similar protection as "safe RET" above
but employs an IBPB barrier on privilege
domain crossings (User->Kernel,
Guest->Host).
Note that User->User mitigation is controlled by how the IBPB aspect in
the Spectre v2 mitigation is selected:

(spec_rstack_overflow=ibpb)
* 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.

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: 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:

Expand Down

0 comments on commit 09f9f37

Please sign in to comment.