[v2,2/2] Documentation/hw-vuln: Document the interaction between IBRS and STIBP
Commit Message
Explain why STIBP is needed with legacy IBRS as currently implemented
(KERNEL_IBRS) and why STIBP is not needed when enhanced IBRS is enabled.
Signed-off-by: KP Singh <kpsingh@kernel.org>
---
Documentation/admin-guide/hw-vuln/spectre.rst | 22 ++++++++++++++-----
1 file changed, 17 insertions(+), 5 deletions(-)
Comments
On Tue, Feb 21, 2023 at 07:49:08PM +0100, KP Singh wrote:
> ... Consequently, STIBP needs to be explicitly
> + enabled to guard against cross-thread attacks in userspace.
needs?
That sounds like something the user needs to do. But we do it by
default. Let's rephrase:
"Systems which support enhanced IBRS (eIBRS) enable IBRS protections once at
boot and they're automatically protected against Spectre v2 variant
attacks, including cross-thread branch target injections on SMT systems
(STIBP). IOW, eIBRS enables STIBP too.
Legacy IBRS systems clear the IBRS bit on exit to userspace and
therefore explicitly enable STIBP for that."
Simple.
On Thu, Feb 23, 2023 at 9:52 AM Borislav Petkov <bp@alien8.de> wrote:
>
> On Tue, Feb 21, 2023 at 07:49:08PM +0100, KP Singh wrote:
> > ... Consequently, STIBP needs to be explicitly
> > + enabled to guard against cross-thread attacks in userspace.
>
> needs?
>
> That sounds like something the user needs to do. But we do it by
> default. Let's rephrase:
>
> "Systems which support enhanced IBRS (eIBRS) enable IBRS protections once at
> boot and they're automatically protected against Spectre v2 variant
> attacks, including cross-thread branch target injections on SMT systems
> (STIBP). IOW, eIBRS enables STIBP too.
>
> Legacy IBRS systems clear the IBRS bit on exit to userspace and
> therefore explicitly enable STIBP for that."
ack, I will respin both patches with your suggestions.
- KP
>
> Simple.
>
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
On Thu, Feb 23, 2023 at 9:52 AM Borislav Petkov <bp@alien8.de> wrote:
>
> On Tue, Feb 21, 2023 at 07:49:08PM +0100, KP Singh wrote:
> > ... Consequently, STIBP needs to be explicitly
> > + enabled to guard against cross-thread attacks in userspace.
>
> needs?
>
> That sounds like something the user needs to do. But we do it by
> default. Let's rephrase:
>
> "Systems which support enhanced IBRS (eIBRS) enable IBRS protections once at
> boot and they're automatically protected against Spectre v2 variant
> attacks, including cross-thread branch target injections on SMT systems
> (STIBP). IOW, eIBRS enables STIBP too.
>
> Legacy IBRS systems clear the IBRS bit on exit to userspace and
> therefore explicitly enable STIBP for that."
+ Systems which support enhanced IBRS (eIBRS) enable IBRS protection once at
+ boot, by setting the IBRS bit, and they're automatically protected against
+ Spectre v2 variant attacks, including cross-thread branch target injections
+ on SMT systems (STIBP). In other words, eIBRS enables STIBP too.
+
+ Legacy IBRS systems clear the IBRS bit on exit to userspace and
+ therefore explicitly enable STIBP for that
I did add one phrase, we really need to stress on the IBRS bit here.
Had we been enabling KERNEL_IBRS accidentally with eIBRS, it would
still mess things up as the bit being set is important.
This is why my original patch felt "obtuse" as it focused on
KERNEL_IBRS instead of IBRS or eIBRS :).
>
> Simple.
>
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
@@ -479,8 +479,17 @@ Spectre variant 2
On Intel Skylake-era systems the mitigation covers most, but not all,
cases. See :ref:`[3] <spec_ref3>` for more details.
- On CPUs with hardware mitigation for Spectre variant 2 (e.g. Enhanced
- IBRS on x86), retpoline is automatically disabled at run time.
+ On CPUs with hardware mitigation for Spectre variant 2 (e.g. IBRS
+ or enhanced IBRS on x86), retpoline is automatically disabled at run time.
+
+ Setting the IBRS bit implicitly enables STIBP which guards against
+ cross-thread branch target injection on SMT systems. On systems with enhanced
+ IBRS, the kernel sets the bit once, which keeps cross-thread protections
+ always enabled, obviating the need for an explicit STIBP. On CPUs with legacy
+ IBRS, the kernel clears the IBRS bit on returning to user-space, thus also
+ disabling the implicit STIBP. Consequently, STIBP needs to be explicitly
+ enabled to guard against cross-thread attacks in userspace.
+
The retpoline mitigation is turned on by default on vulnerable
CPUs. It can be forced on or off by the administrator
@@ -504,9 +513,12 @@ Spectre variant 2
For Spectre variant 2 mitigation, individual user programs
can be compiled with return trampolines for indirect branches.
This protects them from consuming poisoned entries in the branch
- target buffer left by malicious software. Alternatively, the
- programs can disable their indirect branch speculation via prctl()
- (See :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`).
+ target buffer left by malicious software.
+
+ On legacy IBRS systems, at return to userspace, implicit STIBP is disabled
+ because the kernel clears the IBRS bit. In this case, the userspace programs
+ can disable indirect branch speculation via prctl() (See
+ :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`).
On x86, this will turn on STIBP to guard against attacks from the
sibling thread when the user program is running, and use IBPB to
flush the branch target buffer when switching to/from the program.