lkml.org 
[lkml]   [2018]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2] x86/speculation: Add support for STIBP always-on preferred mode
On Wed, 12 Dec 2018, Borislav Petkov wrote:
> On Tue, Dec 11, 2018 at 10:46:16PM +0000, Lendacky, Thomas wrote:
> > + /*
> > + * At this point, an STIBP mode other than "off" has been set.
> > + * If STIBP support is not being forced, check if STIBP always-on
> > + * is preferred.
> > + */
> > + if (mode != SPECTRE_V2_USER_STRICT &&
> > + boot_cpu_has(X86_FEATURE_AMD_STIBP_ALWAYS_ON)) {
> > + stibp_always_on = true;
> > + mode = SPECTRE_V2_USER_STRICT;
> > + pr_info("mitigation: STIBP always-on is preferred\n");
> > + }
> > +
> > /* Initialize Indirect Branch Prediction Barrier */
> > if (boot_cpu_has(X86_FEATURE_IBPB)) {
> > setup_force_cpu_cap(X86_FEATURE_USE_IBPB);
> > @@ -1088,7 +1102,8 @@ static char *stibp_state(void)
> > case SPECTRE_V2_USER_NONE:
> > return ", STIBP: disabled";
> > case SPECTRE_V2_USER_STRICT:
> > - return ", STIBP: forced";
> > + return stibp_always_on ? ", STIBP: always-on"
> > + : ", STIBP: forced";
>
> 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:

> > - 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?

tglx

\
 
 \ /
  Last update: 2018-12-12 04:41    [W:0.116 / U:0.828 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site