public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
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,
	pawan.kumar.gupta@linux.intel.com, kim.phillips@amd.com,
	alexandre.chartre@oracle.com, daniel.sneddon@linux.intel.com,
	corbet@lwn.net, bp@suse.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: Tue, 21 Feb 2023 20:47:38 +0100	[thread overview]
Message-ID: <Y/Uf2lnU/VcsFs1O@kroah.com> (raw)
In-Reply-To: <CACYkzJ7pLhJ+NfUq36PaMxadkgv-cPtO60TW=g_Nh7vU1vEWqA@mail.gmail.com>

On Tue, Feb 21, 2023 at 11:35:29AM -0800, KP Singh wrote:
> On Tue, Feb 21, 2023 at 11:29 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, Feb 21, 2023 at 07:49:07PM +0100, KP Singh wrote:
> > > Setting the IBRS bit implicitly enables STIBP to protect against
> > > cross-thread branch target injection. With enhanced IBRS, the bit it set
> > > once and is not cleared again. However, on CPUs with just legacy IBRS,
> > > IBRS bit set on user -> kernel and cleared on kernel -> user (a.k.a
> > > KERNEL_IBRS). Clearing this bit also disables the implicitly enabled
> > > STIBP, thus requiring some form of cross-thread protection in userspace.
> > >
> > > Enable STIBP, either opt-in via prctl or seccomp, or always on depending
> > > on the choice of mitigation selected via spectre_v2_user.
> > >
> > > Reported-by: José Oliveira <joseloliveira11@gmail.com>
> > > Reported-by: Rodrigo Branco <rodrigo@kernelhacking.com>
> > > Reviewed-by: Alexandra Sandulescu <aesa@google.com>
> > > Fixes: 7c693f54c873 ("x86/speculation: Add spectre_v2=ibrs option to support Kernel IBRS")
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: KP Singh <kpsingh@kernel.org>
> > > ---
> > >  arch/x86/kernel/cpu/bugs.c | 33 ++++++++++++++++++++++-----------
> > >  1 file changed, 22 insertions(+), 11 deletions(-)
> >
> > Why isn't patch 2/2 for stable as well?
> 
> It should be. I actually forgot to remove stable from the first one as
> there are still ongoing discussions and people kept having to "drop
> stable".  I can send a v3 with stable Cc'ed. Should it have a fixes
> tag too?

Why does anyone need to "drop stable" from a patch discussion?  That's
not a problem, we _WANT_ to see the patch review and discussion also
copied there to be aware of what is coming down the pipeline.  So
whomever said that is not correct, sorry.

And yes, a fixes: tag would be nice.

thanks,

greg k-h

  reply	other threads:[~2023-02-21 19:47 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-21 18:49 [PATCH v2 1/2] x86/speculation: Allow enabling STIBP with legacy IBRS 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 [this message]
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
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=Y/Uf2lnU/VcsFs1O@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=aesa@google.com \
    --cc=alexandre.chartre@oracle.com \
    --cc=bp@suse.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=pawan.kumar.gupta@linux.intel.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