lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 3 Sep 2018 10:51:22 +0200 (CEST)
From:   Jiri Kosina <>
To:     Thomas Gleixner <>,
        Ingo Molnar <>,
        Peter Zijlstra <>,
        Josh Poimboeuf <>,
        Andrea Arcangeli <>,
        "Woodhouse, David" <>
Subject: Re: [PATCH] x86/speculation: Enable cross-hyperthread spectre v2
 STIBP mitigation

On Fri, 31 Aug 2018, Jiri Kosina wrote:

> From: Jiri Kosina <>
> 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:
> Signed-off-by: Jiri Kosina <>
> ---
> 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

Powered by blists - more mailing lists