From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Wed, 24 Jan 2018 10:10:49 +0100
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	KarimAllah Ahmed <karahmed@amazon.de>, linux-kernel@vger.kernel.org,
	Andi Kleen <ak@linux.intel.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	Arjan van de Ven <arjan@linux.intel.com>,
	Ashok Raj <ashok.raj@intel.com>,
	Asit Mallick <asit.k.mallick@intel.com>,
	Borislav Petkov <bp@suse.de>,
	Dan Williams <dan.j.williams@intel.com>,
	Dave Hansen <dave.hansen@intel.com>,
	"H . Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	Janakarajan Natarajan <Janakarajan.Natarajan@amd.com>,
	Joerg Roedel <joro@8bytes.org>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Laura Abbott <labbott@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Radim =?utf-8?B?S3LEjW3DocWZ?= <rkrcmar@redhat.com>,
	Tim Chen <tim.c.chen@linux.intel.com>,
	Tom Lendacky <thomas.lendacky@amd.com>, kvm@vger.kernel.org,
	x86@kernel.org
Subject: Re: [RFC 05/10] x86/speculation: Add basic IBRS support
 infrastructure
Message-ID: <20180124091049.GB12100@kroah.com>
References: <1516476182-5153-1-git-send-email-karahmed@amazon.de>
 <1516476182-5153-6-git-send-email-karahmed@amazon.de>
 <alpine.DEB.2.20.1801211524160.1998@nanos>
 <1516741116.13558.11.camel@infradead.org>
 <20180124084735.GM2228@hirez.programming.kicks-ass.net>
 <1516784541.13558.90.camel@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1516784541.13558.90.camel@infradead.org>
User-Agent: Mutt/1.9.2 (2017-12-15)
X-Mailing-List: linux-kernel@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>

On Wed, Jan 24, 2018 at 09:02:21AM +0000, David Woodhouse wrote:
> On Wed, 2018-01-24 at 09:47 +0100, Peter Zijlstra wrote:
> > Typically tglx likes to use x86_match_cpu() for these things; see also
> > commit: bd9240a18edfb ("x86/apic: Add TSC_DEADLINE quirk due to
> > errata").
> 
> Thanks, will fix. I think we might also end up in whitelist mode,
> adding "known good" microcodes to the list as they get released or
> retroactively blessed.
> 
> I would really have liked a new bit in IA32_ARCH_CAPABILITIES to say
> that it's safe, but that's not possible for *existing* microcode which
> actually turns out to be OK in the end.
> 
> That means the whitelist ends up basically empty right now. Should I
> add a command line parameter to override it? Otherwise we end up having
> to rebuild the kernel every time there's a microcode release which
> covers a new CPU SKU (which is why I kind of hate the whitelist, but
> Arjan is very insistent...)

Ick, no, whitelists are a pain for everyone involved.  Don't do that
unless it is absolutely the only way it will ever work.

Arjan, why do you think this can only be done as a whitelist?

It's much easier to just mark the "bad" microcode versions as those
_should_ be a much smaller list that Intel knows about today.  And of
course, any future microcode updates will not be "bad" because they know
how to properly test for this now before they are released :)

thanks,

greg k-h