mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Dave Hansen <dave.hansen@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linuxfoundation.org>,
	x86@kernel.org, Borislav Petkov <bp@alien8.de>,
	Tim Chen <tim.c.chen@linux.intel.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Andi Kleen <ak@linux.intel.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Andy Lutomirski <luto@kernel.org>,
	Arjan Van De Ven <arjan.van.de.ven@intel.com>
Subject: Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code
Date: Wed, 10 Jan 2018 12:45:05 +0100	[thread overview]
Message-ID: <20180110114505.GO6176@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <1515583373.22302.109.camel@infradead.org>

On Wed, Jan 10, 2018 at 11:22:53AM +0000, David Woodhouse wrote:
> On Wed, 2018-01-10 at 11:03 +0100, Peter Zijlstra wrote:
> > On Wed, Jan 10, 2018 at 09:27:59AM +0000, David Woodhouse wrote:
> > > 
> > > > 
> > > > The only question I have is if retpoline works at all on SKL (with ucode
> > > > update); BDW needs the ucode update for retpoline to work because of the
> > > > RSB fallback.
> > > As I understand it, Skylake is never getting the IBRS_ATT (all the
> > > time) feature. That is for future CPUs only.
> >
> > Ah, so then I got confused by your earlier email. So retpoline will work
> > on SKL, but it will, like BDW need the ucode update?
> 
> Er, ... I'm not sure if SKL does need the µcode update. As I understand
> it, the µcode update for BDW stops it from taking predictions for 'ret'
> from anything but the RSB, which means that RSB-stuffing is sufficient.

OK, that is what I understood as well.

> On SKL I don't think there *is* a way to stop it doing that, which is
> why we were originally saying we'd use IBRS on SKL instead.

Ah, so we need the dynamic IBRS cruft for SKL :/ I really detest the
IBRS 'feature' it would be ever so much better if we can otherwise fix
that RSB issue, but I suppose people have looked at that already.

> > Yes, continuation of the nomenclature of that earlier thread.
> 
> Except I don't think it is; I think the various IBRS= options there
> were about pointlessly fine-tuning when you frob the *existing* IBRS
> bit, not about the future IBRS_ATT bit which really is set-and-forget.

IBRS=1 was the dynamic mumbo jumbo, IBRS=2 set it once at CPU bringup
and leave it on (or rather, that was the intention, patch had holes)
IIRC.

> > Still, point remains, do we ever need that MSR fiddling dynamic IBRS
> > stuff now that we have retpolines? I would prefer to not have it if
> > there is no compelling reason for it.
> 
> We do want IBPB if we want to protect userspace processes (and VM
> guests) from each other. Although the attack mode there is relatively
> hard so *perhaps* we can resort to prayer instead?

Sure, not arguing about IBPB, I understand that bit.

> For IBRS though... yeah, good question. It *does* give additional
> protection on SKL where 'ret' might get mispredicted and the RSB-
> stuffing is not always guaranteed to be sufficient, but appealing to
> the deity of your choice might also be an acceptable mitigation there?

I'm just trying to understand the various undocumented options here. As
pjt [1] put it nicely:

"The majority of the confusion does not stem from this being complicated.
 It's that there's been great reluctance to document the details"

There just isn't clear and coherent information on this stuff around, so
everybody gets confused.


[1] https://lkml.kernel.org/r/CAPM31RKV-P40P0yUy7QjvsWT7sr2wUrBzqj_ma1trAjNiBWM3w@mail.gmail.com

  parent reply	other threads:[~2018-01-10 11:45 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-10  1:06 [patch RFC 0/5] x86/spectre_v2: Initial integration of IBRS into the spectre_v2 mechanics Thomas Gleixner
2018-01-10  1:06 ` [patch RFC 1/5] x86/CPU: Sync CPU feature flags late Thomas Gleixner
2018-01-10  1:37   ` Dave Hansen
2018-01-10  1:39     ` Van De Ven, Arjan
2018-01-10  1:47       ` Thomas Gleixner
2018-01-10  2:57         ` Andy Lutomirski
2018-01-10 11:02           ` Thomas Gleixner
2018-01-10  1:44     ` Thomas Gleixner
2018-01-10  6:20     ` Ingo Molnar
2018-01-10 11:33       ` Borislav Petkov
2018-01-10 12:38         ` Thomas Gleixner
2018-01-10  1:06 ` [patch RFC 2/5] x86/spectre: Simplify spectre code a bit Thomas Gleixner
2018-01-10  6:22   ` Ingo Molnar
2018-01-10  1:06 ` [patch RFC 3/5] x86/spectre: Prepare for IBRS selection Thomas Gleixner
2018-01-10  1:51   ` Dave Hansen
2018-01-10  1:06 ` [patch RFC 4/5] x86/cpufeatures: Detect Speculation control feature Thomas Gleixner
2018-01-10  6:32   ` Ingo Molnar
2018-01-10 11:06     ` Thomas Gleixner
2018-01-10  1:06 ` [patch RFC 5/5] x86/speculation: Add basic speculation control code Thomas Gleixner
2018-01-10  2:02   ` Dave Hansen
2018-01-10  4:11     ` Justin Forbes
2018-01-10  9:22     ` Peter Zijlstra
2018-01-10  9:27       ` David Woodhouse
2018-01-10 10:03         ` Peter Zijlstra
2018-01-10 11:22           ` David Woodhouse
2018-01-10 11:41             ` Thomas Gleixner
2018-01-10 11:45             ` Peter Zijlstra [this message]
2018-01-10 11:54         ` Andrea Arcangeli
2018-01-10 11:58           ` David Woodhouse
2018-01-10 12:01             ` Andrea Arcangeli
2018-01-10 12:07               ` Andrea Arcangeli
2018-01-10 12:12                 ` David Woodhouse
2018-01-10 12:20                   ` Andrea Arcangeli
2018-01-10 12:27                     ` Andrea Arcangeli
2018-01-10 13:42                     ` Van De Ven, Arjan
2018-01-10 12:09               ` David Woodhouse
2018-01-10 12:17                 ` Andrea Arcangeli
2018-01-10 12:29                   ` David Woodhouse
2018-01-10 12:41                     ` Andrea Arcangeli
2018-01-10 12:47                       ` Jiri Kosina
2018-01-10 12:51                         ` David Woodhouse
2018-01-10 13:02                           ` Andrea Arcangeli
2018-01-10 13:05                             ` Andrea Arcangeli
2018-01-10 13:10                               ` Andrea Arcangeli
2018-01-10 13:12                                 ` Andrea Arcangeli
2018-01-10 12:57                         ` Andrea Arcangeli
2018-01-10 13:07                           ` David Woodhouse
2018-01-10 13:45                             ` Van De Ven, Arjan
2018-01-10 13:52                               ` Andrea Arcangeli
2018-01-10 13:53                                 ` Van De Ven, Arjan
2018-01-10 21:35                                   ` Tim Chen
2018-01-10 22:13                                     ` Andrea Arcangeli
2018-01-10 13:46                             ` Thomas Gleixner
2018-01-10 13:51                               ` Van De Ven, Arjan
2018-01-10 13:53                                 ` Thomas Gleixner
2018-01-10 13:58                               ` David Woodhouse
2018-01-10 14:10                               ` Andrea Arcangeli
2018-01-10 14:14                                 ` Van De Ven, Arjan
2018-01-10 14:59                                 ` Dave Hansen
2018-01-10 15:13                                   ` Andrea Arcangeli
2018-01-10 15:24                                     ` David Woodhouse
2018-01-10 15:47                                       ` Andrea Arcangeli
2018-01-10 15:56                                         ` David Woodhouse
2018-01-10 13:10                           ` Jiri Kosina

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=20180110114505.GO6176@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=aarcange@redhat.com \
    --cc=ak@linux.intel.com \
    --cc=arjan.van.de.ven@intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=dwmw2@infradead.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tim.c.chen@linux.intel.com \
    --cc=torvalds@linuxfoundation.org \
    --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

Powered by JetHome