[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <37cf9ba3941a51e8db27f9f4c21b5b7e.squirrel@twosheds.infradead.org>
Date: Sun, 21 Jan 2018 15:25:38 -0000
From: "David Woodhouse" <dwmw2@...radead.org>
To: "Thomas Gleixner" <tglx@...utronix.de>
Cc: "KarimAllah Ahmed" <karahmed@...zon.de>,
linux-kernel@...r.kernel.org, "Andi Kleen" <ak@...ux.intel.com>,
"Andrea Arcangeli" <aarcange@...hat.com>,
"Andy Lutomirski" <luto@...nel.org>,
"Arjan van de Ven" <arjan@...ux.intel.com>,
"Ashok Raj" <ashok.raj@...el.com>,
"Asit Mallick" <asit.k.mallick@...el.com>,
"Borislav Petkov" <bp@...e.de>,
"Dan Williams" <dan.j.williams@...el.com>,
"Dave Hansen" <dave.hansen@...el.com>,
"David Woodhouse" <dwmw@...zon.co.uk>,
"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
"H . Peter Anvin" <hpa@...or.com>,
"Ingo Molnar" <mingo@...hat.com>,
"Janakarajan Natarajan" <janakarajan.natarajan@....com>,
"Joerg Roedel" <joro@...tes.org>,
"Jun Nakajima" <jun.nakajima@...el.com>,
"Laura Abbott" <labbott@...hat.com>,
"Linus Torvalds" <torvalds@...ux-foundation.org>,
"Masami Hiramatsu" <mhiramat@...nel.org>,
"Paolo Bonzini" <pbonzini@...hat.com>,
"Peter Zijlstra" <peterz@...radead.org>,
"Radim Krčmář" <rkrcmar@...hat.com>,
"Tim Chen" <tim.c.chen@...ux.intel.com>,
"Tom Lendacky" <thomas.lendacky@....com>, kvm@...r.kernel.org,
x86@...nel.org
Subject: Re: [RFC 05/10] x86/speculation: Add basic IBRS support
infrastructure
> On Sat, 20 Jan 2018, KarimAllah Ahmed wrote:
>> From: David Woodhouse <dwmw@...zon.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.
Perhaps we could start with the list already published by VMware at
https://kb.vmware.com/s/article/52345
--
dwmw2
Powered by blists - more mailing lists