linux-kernel - Re: [RFC 05/10] x86/speculation: Add basic IBRS support infrastructure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 24 Jan 2018 10:10:49 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     David Woodhouse <dwmw2@...radead.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        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>,
        "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>,
        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 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