From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
To: KP Singh <kpsingh@kernel.org>
Cc: linux-kernel@vger.kernel.org, pjt@google.com, evn@google.com,
jpoimboe@kernel.org, tglx@linutronix.de, x86@kernel.org,
hpa@zytor.com, peterz@infradead.org, kim.phillips@amd.com,
alexandre.chartre@oracle.com, daniel.sneddon@linux.intel.com,
corbet@lwn.net, bp@alien8.de, linyujun809@huawei.com,
jmattson@google.com, "José Oliveira" <joseloliveira11@gmail.com>,
"Rodrigo Branco" <rodrigo@kernelhacking.com>,
"Alexandra Sandulescu" <aesa@google.com>,
stable@vger.kernel.org
Subject: Re: [PATCH v2 1/2] x86/speculation: Allow enabling STIBP with legacy IBRS
Date: Wed, 22 Feb 2023 00:25:42 -0800 [thread overview]
Message-ID: <20230222082542.bjgwgydfdswkqwre@desk> (raw)
In-Reply-To: <CACYkzJ4efHx2oZUW82m3DGw7ssLq37EFOV57X=kT5fm=6Q7WbQ@mail.gmail.com>
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.
next prev parent reply other threads:[~2023-02-22 8:25 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-21 18:49 KP Singh
2023-02-21 18:49 ` [PATCH v2 2/2] Documentation/hw-vuln: Document the interaction between IBRS and STIBP KP Singh
2023-02-23 14:52 ` Borislav Petkov
2023-02-24 3:30 ` KP Singh
2023-02-26 1:42 ` KP Singh
2023-02-21 19:29 ` [PATCH v2 1/2] x86/speculation: Allow enabling STIBP with legacy IBRS Greg KH
2023-02-21 19:29 ` Greg KH
2023-02-21 19:35 ` KP Singh
2023-02-21 19:47 ` Greg KH
2023-02-21 19:57 ` Borislav Petkov
2023-02-21 20:09 ` Greg KH
2023-02-21 20:23 ` Borislav Petkov
2023-02-22 3:07 ` Pawan Gupta
2023-02-22 5:49 ` KP Singh
2023-02-22 8:25 ` Pawan Gupta [this message]
2023-02-22 12:32 ` Borislav Petkov
2023-02-22 13:56 ` David Laight
2023-02-22 12:24 ` Borislav Petkov
2023-02-22 17:16 ` KP Singh
2023-02-22 17:48 ` Borislav Petkov
2023-02-22 19:41 ` KP Singh
2023-02-23 12:44 ` Borislav Petkov
2023-02-26 1:50 ` KP Singh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230222082542.bjgwgydfdswkqwre@desk \
--to=pawan.kumar.gupta@linux.intel.com \
--cc=aesa@google.com \
--cc=alexandre.chartre@oracle.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=daniel.sneddon@linux.intel.com \
--cc=evn@google.com \
--cc=hpa@zytor.com \
--cc=jmattson@google.com \
--cc=joseloliveira11@gmail.com \
--cc=jpoimboe@kernel.org \
--cc=kim.phillips@amd.com \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linyujun809@huawei.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=rodrigo@kernelhacking.com \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®