Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Borislav Petkov <bp@alien8.de>
To:     X86 ML <x86@kernel.org>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        LKML <linux-kernel@vger.kernel.org>
Subject: [PATCH 3/3] Documentation/srso: Document IBPB aspect and fix formatting
Date:   Wed,  9 Aug 2023 12:27:00 +0200
Message-ID: <20230809102700.29449-4-bp@alien8.de>
In-Reply-To: <20230809102700.29449-1-bp@alien8.de>
References: <20230809102700.29449-1-bp@alien8.de>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

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/a=
dmin-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:
=20
 The possible values in this file are:
=20
- - 'Not affected'               The processor is not vulnerable
+ * 'Not affected':
=20
- - 'Vulnerable: no microcode'   The processor is vulnerable, no
-                                microcode extending IBPB functionality
-                                to address the vulnerability has been
-                                applied.
+   The processor is not vulnerable
=20
- - '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':
=20
-                                (spec_rstack_overflow=3Dmicrocode)
+   The processor is vulnerable, no microcode extending IBPB
+   functionality to address the vulnerability has been applied.
=20
- - 'Mitigation: safe RET'       Software-only mitigation. It complements
-                                the extended IBPB microcode patch
-                                functionality by addressing User->Kernel=
=20
-                                and Guest->Host transitions protection.
+ * 'Mitigation: microcode':
=20
-                                Selected by default or by
-                                spec_rstack_overflow=3Dsafe-ret
+   Extended IBPB functionality microcode patch has been applied. It does
+   not address User->Kernel and Guest->Host transitions protection but i=
t
+   does address User->User and VM->VM attack vectors.
=20
- - '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:
=20
-                                (spec_rstack_overflow=3Dibpb)
+    * 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=3Don on the kernel
+      command line
+
+   (spec_rstack_overflow=3Dmicrocode)
+
+ * '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=3Dsafe-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=3Dibpb)
+
+ * 'Mitigation: IBPB on VMEXIT':
+
+   Mitigation addressing the cloud provider scenario - the Guest->Host
+   transitions only.
+
+   (spec_rstack_overflow=3Dibpb-vmexit)
=20
- - 'Mitigation: IBPB on VMEXIT' Mitigation addressing the cloud provider
-                                scenario - the Guest->Host transitions
-                                only.
=20
-                                (spec_rstack_overflow=3Dibpb-vmexit)
=20
 In order to exploit vulnerability, an attacker needs to:
=20
--=20
2.41.0