From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC 05/10] x86/speculation: Add basic IBRS support
 infrastructure
Date: Sun, 21 Jan 2018 15:31:28 +0100 (CET)
Message-ID: <alpine.DEB.2.20.1801211524160.1998@nanos>
References: <1516476182-5153-1-git-send-email-karahmed@amazon.de> <1516476182-5153-6-git-send-email-karahmed@amazon.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Cc: 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>,
        David Woodhouse <dwmw@amazon.co.uk>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "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.or
To: KarimAllah Ahmed <karahmed@amazon.de>
Return-path: <linux-kernel-owner@vger.kernel.org>
In-Reply-To: <1516476182-5153-6-git-send-email-karahmed@amazon.de>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: kvm.vger.kernel.org

On Sat, 20 Jan 2018, KarimAllah Ahmed wrote:
> From: David Woodhouse <dwmw@amazon.co.uk>
> 
> Not functional yet; just add the handling for it in the Spectre v2
> mitigation selection, and the X86_FEATURE_IBRS flag which will control
> the code to be added in later patches.
> 
> Also take the #ifdef CONFIG_RETPOLINE from around the RSB-stuffing; IBRS
> mode will want that too.
> 
> For now we are auto-selecting IBRS on Skylake. We will probably end up
> changing that but for now let's default to the safest option.
> 
> XX: Do we want a microcode blacklist?

Oh yes, we want a microcode blacklist. Ideally we refuse to load the
affected microcode in the first place and if its already loaded then at
least avoid to use the borked features.

PR texts promising that Intel is committed to transparency in this matter
are not sufficient. Intel, please provide the facts, i.e. a proper list of
micro codes and affected SKUs, ASAP.

Thanks,

	tglx