From: "Borislav Petkov (AMD)" <bp@alien8.de>
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>
---
Documentation/admin-guide/hw-vuln/srso.rst | 71 ++++++++++++++--------
1 file changed, 44 insertions(+), 27 deletions(-)
diff --git a/Documentation/admin-guide/hw-vuln/srso.rst b/Documentation/admin-guide/hw-vuln/srso.rst
index 32eb5e6db272..af59a9395662 100644
--- a/Documentation/admin-guide/hw-vuln/srso.rst
+++ b/Documentation/admin-guide/hw-vuln/srso.rst
@@ -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:
--
2.41.0On Wed, Aug 09, 2023 at 12:27:00PM +0200, Borislav Petkov wrote: > From: "Borislav Petkov (AMD)" <bp@alien8.de> > > 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> > --- > Documentation/admin-guide/hw-vuln/srso.rst | 71 ++++++++++++++-------- > 1 file changed, 44 insertions(+), 27 deletions(-) > > diff --git a/Documentation/admin-guide/hw-vuln/srso.rst b/Documentation/admin-guide/hw-vuln/srso.rst > index 32eb5e6db272..af59a9395662 100644 > --- a/Documentation/admin-guide/hw-vuln/srso.rst > +++ b/Documentation/admin-guide/hw-vuln/srso.rst > @@ -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': All other mitigations capitalizes the first letter, to be consistent s/no microcode/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': Ditto.
The following commit has been merged into the x86/bugs branch of tip:
Commit-ID: 09f9f37c324d90102e8574856ab168c34de1916d
Gitweb: https://git.kernel.org/tip/09f9f37c324d90102e8574856ab168c34de1916d
Author: Borislav Petkov (AMD) <bp@alien8.de>
AuthorDate: Wed, 02 Aug 2023 20:07:32 +02:00
Committer: Borislav Petkov (AMD) <bp@alien8.de>
CommitterDate: Thu, 10 Aug 2023 11:03:12 +02:00
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: 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
---
Documentation/admin-guide/hw-vuln/srso.rst | 71 +++++++++++++--------
1 file changed, 44 insertions(+), 27 deletions(-)
diff --git a/Documentation/admin-guide/hw-vuln/srso.rst b/Documentation/admin-guide/hw-vuln/srso.rst
index 32eb5e6..af59a93 100644
--- a/Documentation/admin-guide/hw-vuln/srso.rst
+++ b/Documentation/admin-guide/hw-vuln/srso.rst
@@ -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:© 2016 - 2025 Red Hat, Inc.