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-next>] [day] [month] [year] [list]

Message-ID: <7EB9643C-D2DD-477A-90DE-05DC653D2D4B@vmware.com>
Date:   Mon, 29 Jan 2018 22:29:28 +0000
From:   David Dunn <ddunn@...are.com>
To:     Eduardo Habkost <ehabkost@...hat.com>
CC:     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>,
        Andi Kleen <ak@...ux.intel.com>,
        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>,
        "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>,
        Jim Mattson <jmattson@...gle.com>,
        David Woodhouse <dwmw2@...radead.org>
Subject: Re: [RFC,05/10] x86/speculation: Add basic IBRS support
 infrastructure

On Mon, 2018-01-29 at 13:45:07 -0800, Eduardo Habkost wrote:

> Maybe a generic "family/model/stepping/microcode really matches
> the CPU you are running on" bit would be useful.  The bit could
> be enabled only on host-passthrough (aka "-cpu host") mode.
> 
> If we really want to be able to migrate to host with different
> CPU models (except Skylake), we could add a more specific "we
> promise the host CPU is never going to be Skylake" bit.
> 
> Now, if the hypervisor is not providing any of those bits, I
> would advise against trusting family/model/stepping/microcode
> under a hypervisor.  Using a pre-defined CPU model (that doesn't
> necessarily match the host) is very common when using KVM VM
> management stacks.
> 

Eduardo,

I don't see how this is possible in a modern virtualization environment.
 
Under VMware, a VM will be migrated to SkyLake if one is in the cluster and supports the features exposed to the VM.  This can occur for suspend/resume as well.

The migration pool isn't a constant.  Hosts can be added to a cluster and VMs can be instructed to move across clusters.  So there doesn't need to be a SkyLake around when the VM powers on in order for it to eventually end up on a SkyLake.

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.

My apologies for posting onto the mailing list out of the blue.  Someone asked my opinion on this suggestion.  I'm definitely interested in figuring out whether Linux can fully mitigate the SkyLake RSB problem in virtual environments, but it's not clear how best to achieve that.

Thanks,

David Dunn