linux-kernel - Re: [PATCH v2 1/2] x86/speculation: Allow enabling STIBP with legacy IBRS

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]

Message-ID: <20230222082542.bjgwgydfdswkqwre@desk>
Date:   Wed, 22 Feb 2023 00:25:42 -0800
From:   Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
To:     KP Singh <kpsingh@...nel.org>
Cc:     linux-kernel@...r.kernel.org, pjt@...gle.com, evn@...gle.com,
        jpoimboe@...nel.org, tglx@...utronix.de, x86@...nel.org,
        hpa@...or.com, peterz@...radead.org, kim.phillips@....com,
        alexandre.chartre@...cle.com, daniel.sneddon@...ux.intel.com,
        corbet@....net, bp@...en8.de, linyujun809@...wei.com,
        jmattson@...gle.com,
        José Oliveira <joseloliveira11@...il.com>,
        Rodrigo Branco <rodrigo@...nelhacking.com>,
        Alexandra Sandulescu <aesa@...gle.com>, stable@...r.kernel.org
Subject: Re: [PATCH v2 1/2] x86/speculation: Allow enabling STIBP with legacy
 IBRS

On Tue, Feb 21, 2023 at 09:49:57PM -0800, KP Singh wrote:
> > > @@ -1193,13 +1209,8 @@ spectre_v2_user_select_mitigation(void)
> > >                       "always-on" : "conditional");
> > >       }
> > >
> > > -     /*
> > > -      * If no STIBP, IBRS or enhanced IBRS is enabled, or SMT impossible,
> > > -      * STIBP is not required.
> > > -      */
> > > -     if (!boot_cpu_has(X86_FEATURE_STIBP) ||
> > > -         !smt_possible ||
> > > -         spectre_v2_in_ibrs_mode(spectre_v2_enabled))
> > > +     if (!boot_cpu_has(X86_FEATURE_STIBP) || !smt_possible ||
> > > +         !spectre_v2_user_needs_stibp(spectre_v2_enabled))
> >
> > As pointed out in other discussions, it will be great if can get rid of
> > eIBRS check, and do what the user asked for; or atleast print a warning
> 
> I think I will keep it as pr_info as, with eIBRS, the user does not
> really need STIBP and the mitigation is still effective.

Thats fair.

> > about not setting STIBP bit explicitly.
> 
> That is a bit more complicated as, for now, the user is not really
> exposed to STIBP explicitly yet.

> I would prefer to do it as a follow up and fix this bug first.

On a second thought, STIBP bit being explicitly set or not shouldn't
matter as long as user is getting the STIBP protection that it asked
for.

A print may just help catch some bugs sooner than later.

> It's a bit gnarly and I think we really need to think about the
> options that are exposed to the user [especially in light of Intel /
> AMD subtelties].

With AMD's AutoIBRS support landing in mainline, and both (AutoIBRS and
eIBRS) sharing the same =eibrs mitigation mode, those subtelties becomes
more important.

Following up on Andrew's comment in the other thread, I hope AutoIBRS
does not require setting STIBP explicitly?:

  /sigh so we're still talking about 3 different things then.

  1) Intel's legacy IBRS
  2) AMD's regular IBRS
  3) AMD's AutoIBRS

  which all have different relevant behaviours for userspace.  Just so
  it's written out coherently in at least one place...
  [...]
  For any AMD configuration setting STIBP, there must be an IBPB after
  having set STIBP.   Setting STIBP alone does not evict previously
  created shared predictions.  This one can go subtly wrong for anyone
  who assumes that Intel STIBP and AMD STIBP have the same behaviour.