The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	Jiri Kosina <jikos@kernel.org>,
	"asit.k.mallick" <asit.k.mallick@intel.com>,
	"Van De Ven, Arjan" <arjan.van.de.ven@intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Dave Hansen <dave.hansen@intel.com>,
	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>,
	Andi Kleen <ak@linux.intel.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Andy Lutomirski <luto@kernel.org>
Subject: Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code
Date: Wed, 10 Jan 2018 14:46:22 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.20.1801101424180.1919@nanos> (raw)
In-Reply-To: <1515589641.22302.145.camel@infradead.org>

On Wed, 10 Jan 2018, David Woodhouse wrote:
> Andrea, what you're saying is directly contradicting what I've heard
> from Intel.
> 
> The documentation already distinguishes between IBRS on current
> hardware, and IBRS_ATT on future hardware. If it was the case that IBRS
> on current hardware is a set-and-forget option and completely disables
> branch prediction, then they would say that. Rather than explicitly
> saying the *opposite*, specifically for the case of current hardware,
> as they do.
> 
> Rather than continuing to debate it, perhaps it's best just to wake for
> the US to wake up, and Intel to give a definitive answer.

So here is the simple list of questions all to be answered with YES or
NO. I don't want to see any of the 'but, though ...'. We all know by now
that it's CPU dependent and slow and whatever and that IBRS_ATT will be in
future CPUs. So get your act together and tell a clear YES or NO.

1) Does IBRS=1 when set once act as a set-and-forget option ?

 1a) If the answer to #1 is yes, is it more secure than toggling it?

 1b) If the answer to #1 is yes, is retpoline required ?

 1c) If the answer to #1 is yes, is RSB stuffing required ?

2) Does toggle mode of IBRS require retpoline ?

3) Does toggle mode of IBRS require RSB stuffing ?

4) Exist CPUs which require IBRS to be selected automatically ?

   4b) If yes, provide the list as a separate answer please

Thanks,

	tglx

  parent reply	other threads:[~2018-01-10 13:46 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
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 [this message]
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=alpine.DEB.2.20.1801101424180.1919@nanos \
    --to=tglx@linutronix.de \
    --cc=aarcange@redhat.com \
    --cc=ak@linux.intel.com \
    --cc=arjan.van.de.ven@intel.com \
    --cc=asit.k.mallick@intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=dwmw2@infradead.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jikos@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=peterz@infradead.org \
    --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