lkml.org 
[lkml]   [2018]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation
On Fri, 31 Aug 2018, Jiri Kosina wrote:

> From: Jiri Kosina <jkosina@suse.cz>
>
> STIBP is a feature provided by certain Intel ucodes / CPUs. This feature
> (once enabled) prevents cross-hyperthread control of decisions made by
> indirect branch predictors.
>
> Enable this feature if
>
> - the CPU is vulnerable to spectre v2
> - the CPU supports SMT
> - spectre_v2 mitigation autoselection is enabled (default)
>
> After some previous discussion, this patch leaves STIBP on all the time,
> as wrmsr on crossing kernel boundary is a no-no. This could perhaps later
> be a bit more optimized (like disabling it in NOHZ, experiment with
> disabling it in idle, etc) if needed.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
> ---
>
> Let's add the most basic STIBP support, as it has been kind of lost in all
> the previous noise.

After some discussions with Peter, this actually makes a little sense with
the IBPB implementation we currently have upstream, as that's basically
never used (I thought upstream had the same what distros had -- IBPB
issued in cases where tasks can't ptrace each other, but that apparently
got ditched in the process for some reason).

If the argument was that this is too expensive performance-wise, well,
then there is nospectre_v2 for those who are fine with that.

Given the fact that the attack is real, I think we should default to
STIBP+IBPB in the non-ptrace-capable case. Some distros (SUSE for example)
do issue the IBPB in such a way.

I'll submit v2 with that later today.

--
Jiri Kosina
SUSE Labs

\
 
 \ /
  Last update: 2018-09-03 10:52    [W:0.105 / U:3.664 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site