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:   Tue, 30 Jan 2018 01:20:52 +0000
From:   David Dunn <ddunn@...are.com>
To:     Eduardo Habkost <ehabkost@...hat.com>,
        Jim Mattson <jmattson@...gle.com>
CC:     Andi Kleen <ak@...ux.intel.com>,
        Arjan van de Ven <arjan@...ux.intel.com>,
        KarimAllah Ahmed <karahmed@...zon.de>,
        "Wilson, Matt" <msw@...zon.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Andrea Arcangeli" <aarcange@...hat.com>,
        Andy Lutomirski <luto@...nel.org>,
        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>,
        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>,
        Thomas Gleixner <tglx@...utronix.de>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Tom Lendacky <thomas.lendacky@....com>,
        "Jorgensen, Bryan" <bryan.jorgensen@...el.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "Dr. David Alan Gilbert" <dgilbert@...hat.com>,
        Fred Jacobs <fjacobs@...are.com>,
        "David Woodhouse" <dwmw2@...radead.org>
Subject: Re: [RFC,05/10] x86/speculation: Add basic IBRS support
 infrastructure

Eduardo,

This is why it would be good to have a CPUID bit that says: "apply SkyLake RSB stuffing."  That's preferable to "trust FMS" for VMware.

If Intel defines such a feature flag, sets it on SkyLake, and Linux uses it... that would be very helpful for VMware.

I won't speak for GCE and AWS.  But hopefully they can indicate whether it would help them as well.

If Intel cannot define/implement such a flag on SkyLake, then maybe the engineers on this email could define a flag in the hypervisor specific CPUID space.  Linux would need to query that flag if it sees CPUID[1].ECX[31] set.  That's not as nice since it makes detection on bare metal and virtualization platforms different, but it better than keying off FMS.

David Dunn

On 1/29/18, 5:11 PM, "Eduardo Habkost" <ehabkost@...hat.com> wrote:

    On Mon, Jan 29, 2018 at 02:49:51PM -0800, Jim Mattson wrote:
    > And if we expect to introduce Cascade Lake into the pool in the
    > future, we use a Cascade Lake model number?
    > 
    > It sounds like you are suggesting that we set the model number to the
    > highest model number that will ever be introduced into the pool, at
    > any time in the future. That approach would also fail the
    > 'is_skylake_era()' test. (Not to mention that we have no idea what
    > Intel's highest compatible model number will be.)
    
    Exactly, that's why virtualization and live-migration break the
    model of just checking f/m/s/microcode: the guest doesn't need to
    work around bugs that are present in the current host, but the
    set of bugs that could appear on any future host it can run on.
    
    > 
    > On Mon, Jan 29, 2018 at 2:41 PM, Andi Kleen <ak@...ux.intel.com> wrote:
    > >> Even if we expose bit to indicate that FMS matches the underlying host, when does the guest know to query that?  The VM can be moved at any point in time, including after the guest asks if FMS matches host.
    > >
    > > There's no way to enable these mitigations later, so if you always
    > > have to enable the super set of all the mitigations for all the hosts you
    > > might be migrating too.
    > >
    > > As of currently that means if you want to ever migrate to Skylake you should
    > > set the Skylake model number and you're good.
    > >
    > > -Andi
    
    -- 
    Eduardo