Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 26 Jan 2018 10:40:37 +0100
From:   Ingo Molnar <mingo@kernel.org>
To:     David Woodhouse <dwmw2@infradead.org>
Cc:     Thomas Gleixner <tglx@linutronix.de>, arjan@linux.intel.com,
        karahmed@amazon.de, x86@kernel.org, linux-kernel@vger.kernel.org,
        tim.c.chen@linux.intel.com, bp@alien8.de, peterz@infradead.org,
        pbonzini@redhat.com, ak@linux.intel.com,
        torvalds@linux-foundation.org, gregkh@linux-foundation.org,
        dave.hansen@intel.com, gnomes@lxorguk.ukuu.org.uk,
        ashok.raj@intel.com
Subject: Re: [PATCH v4 6/7] x86/cpufeature: Blacklist SPEC_CTRL on early
 Spectre v2 microcodes
Message-ID: <20180126094036.uqi5w4qfvbuic37t@gmail.com>
References: <1516872189-16577-1-git-send-email-dwmw@amazon.co.uk>
 <1516872189-16577-7-git-send-email-dwmw@amazon.co.uk>
 <1516876994.30244.51.camel@infradead.org>
 <alpine.DEB.2.20.1801251146450.2020@nanos>
 <1516879213.30244.74.camel@infradead.org>
 <alpine.DEB.2.20.1801251221360.2020@nanos>
 <1516887714.30244.121.camel@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1516887714.30244.121.camel@infradead.org>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


* David Woodhouse <dwmw2@infradead.org> wrote:

> On Thu, 2018-01-25 at 12:34 +0100, Thomas Gleixner wrote:
> > 
> > This stuff is really a master piece of trainwreck engineering.
> > 
> > So yeah, whatever we do we end up with a proper mess. Lets go for a
> > blacklist and hope that we'll have something which holds at some
> > foreseeable day in the future.
> > 
> > The other concern I have is IBRS vs. IBPB. Are we sufficiently sure that
> > IBPB is working on those IBRS blacklisted ucode revisions? Or should we
> > just play safe and not touch any of this at all when we detect a
> > blacklisted one?
> 
> That isn't sufficiently clear to me. I've changed it back to blacklist
> *everything* for now, to be safe. If at any point Intel want to get
> their act together and give us coherent information to the contrary, we
> can change to separate IBPB/IBRS blacklists.

Yes.

I also agree that blacklists are the fundamentally correct approach here: a 
bit-rotting blacklist is far better to users than a bit-rotting whitelist, 
assuming that the number of CPU and microcode bugs goes down with time.

Thanks,

	Ingo