lists.openwall.net   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  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 31 Oct 2020 09:50:09 -0500
From:   Tom Lendacky <thomas.lendacky@....com>
To:     Anand K Mistry <amistry@...gle.com>, x86@...nel.org,
        linux-kernel@...nel.org
Cc:     joelaf@...gle.com, asteinhauser@...gle.com, tglx@...utronix.de,
        Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Mark Gross <mgross@...ux.intel.com>,
        Mike Rapoport <rppt@...nel.org>,
        Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
        Tony Luck <tony.luck@...el.com>,
        Vineela Tummalapalli <vineela.tummalapalli@...el.com>,
        Waiman Long <longman@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/1] x86/speculation: Allow IBPB to be conditionally
 enabled on CPUs with always-on STIBP

On 10/29/20 1:51 AM, Anand K Mistry wrote:
> When attempting to do some performance testing of IBPB on and AMD
> platform, I noticed the IBPB instruction was never being issued, even
> though it was conditionally on and various seccomp protected processes
> were force enabling it. Turns out, on those AMD CPUs, STIBP is set to
> always-on and this was causing an early-out on the prctl() which turns
> off IB speculation. Here is my attempt to fix it.
> 
> I'm hoping someone that understands this better than me can explain why
> I'm wrong.

It all looks reasonable to me (some comments in the patch to follow). The 
thing that makes this tough is the command line option of being able to 
force IBPB using the "prctl,ibpb" or "seccomp,ibpb" while STIBP is prctl 
or seccomp controlled. There's an inherent quality that is assumed that if 
STIBP is forced then IBPB must be forced and it looks like 21998a351512 
("x86/speculation: Avoid force-disabling IBPB based on STIBP and enhanced 
IBRS.") used that. However, with the STIBP always on support, that doesn't 
hold true.

Thanks,
Tom

> 
> 
> Anand K Mistry (1):
>    x86/speculation: Allow IBPB to be conditionally enabled on CPUs with
>      always-on STIBP
> 
>   arch/x86/kernel/cpu/bugs.c | 41 +++++++++++++++++++++-----------------
>   1 file changed, 23 insertions(+), 18 deletions(-)
> 

Powered by blists - more mailing lists