linux-kernel - Re: [PATCH v2] x86/speculation: Add support for STIBP always-on preferred mode

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 12 Dec 2018 06:23:25 -0800 (PST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     "Lendacky, Thomas" <Thomas.Lendacky@....com>
cc:     Borislav Petkov <bp@...en8.de>, "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        Jiri Kosina <jkosina@...e.cz>, Ingo Molnar <mingo@...hat.com>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        David Woodhouse <dwmw@...zon.co.uk>
Subject: Re: [PATCH v2] x86/speculation: Add support for STIBP always-on
 preferred mode

On Wed, 12 Dec 2018, Lendacky, Thomas wrote:
> On 12/11/2018 09:37 PM, Thomas Gleixner wrote:
> > On Wed, 12 Dec 2018, Borislav Petkov wrote:
> >> I still don't like that separate stibp_always_on variable when we can do
> >> all the querying just by using mode and X86_FEATURE_AMD_STIBP_ALWAYS_ON.
> > 
> > Hmmm. I've not seen the V1 of this (it's not in my inbox) but the v1->v2
> > changes contain:
> 
> That's strange, you were on the cc: list. Anyway, here's a link to the
> first version: https://lkml.org/lkml/2018/12/11/1248

Must have been my sleep deprived brain. Found it now :) Sorry for not
paying attention back then.

> >>> - Removed explicit SPECTRE_V2_USER_STRICT_PREFERRED mode
> > 
> > Now I really have to ask why?
> > 
> > Neither the extra variable nor the cpu feature check are pretty. An
> > explicit mode is way better in terms of code clarity and you get the proper
> > printout via spectre_v2_user_strings.
> > 
> > Hmm?
> 
> That is what the first version did. See if that's in-line with what
> you're thinking.

Yes, though I'm not too fond about the preferred wording, but can't come up
with anything better.

Thanks,

	tglx