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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 31 Jan 2018 10:03:51 -0500
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Andi Kleen <ak@...ux.intel.com>, Jim Mattson <jmattson@...gle.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        David Woodhouse <dwmw2@...radead.org>,
        Arjan van de Ven <arjan@...ux.intel.com>,
        Eduardo Habkost <ehabkost@...hat.com>,
        KarimAllah Ahmed <karahmed@...zon.de>,
        Linux Kernel Mailing List <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>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        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 list <kvm@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        "Dr. David Alan Gilbert" <dgilbert@...hat.com>
Subject: Re: [RFC,05/10] x86/speculation: Add basic IBRS support
 infrastructure

On 29/01/2018 22:13, Andi Kleen wrote:
>> What happens when someone introduces a
>> workaround tied to some other model numbers?
> There are already many of those in the tree for other issues and features. 
> So far you managed to survive without. Likely that will be true
> in the future too.

"Guests have to live with processor fuckups" is actually a much better
answer than "Hypervisors may need to revisit their practice", since at
least it's clear where the blame lies.

Because really it's just plain luck.  It just happens that most errata
are for functionality that is not available to a virtual machine (e.g.
perfmon and monitor workarounds or buggy TSC deadline timer that
hypervisors emulate anyway), that only needs a chicken bit to be set in
the host, or the bugs are there only for old hardware that doesn't have
virtualization (X86_BUG_F00F, X86_BUGS_SWAPGS_FENCE).

CPUID flags are guaranteed to never change---never come, never go away.
For anything that doesn't map nicely to a CPUID flag, you cannot really
express it.  Also if something is not architectural, you can pretty much
assume that you cannot know it under virtualization.  f/m/s is not
architectural; family, model and stepping mean absolutely nothing when
running in virtualization, because the host CPU model can change under
your feet at any time.  We force guest vendor == host vendor just
because otherwise too much stuff breaks, but that's it.

Paolo