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, 31 Jan 2018 11:05:15 +0100
From:   Christophe de Dinechin <christophe.de.dinechin@...il.com>
To:     Alan Cox <gnomes@...rguk.ukuu.org.uk>
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>,
        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>,
        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 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 30 Jan 2018, at 21:46, Alan Cox <gnomes@...rguk.ukuu.org.uk> wrote:
> 
>> If you are ever going to migrate to Skylake, I think you should just
>> always tell the guests that you're running on Skylake. That way the
>> guests will always assume the worst case situation wrt Specte.
> 
> Unfortunately if you do that then guest may also decide to use other
> Skylake hardware features and pop its clogs when it finds out its actually
> running on Westmere or SandyBridge.
> 
> So you need to be able to both lie to the OS and user space via cpuid and
> also have a second 'but do skylake protections' that only mitigation
> aware software knows about.

Yes. The most desirable lie is different depending on whether you want to
allow virtualization features such as migration (where you’d gravitate
towards a CPU with less features) or whether you want to allow mitigation
(where you’d rather present the most fragile CPUID, probably Skylake).

Looking at some recent patches, I’m concerned that the code being added
often assumes that the CPUID is the correct way to get that info.
I do not think this is correct. You really want specific information about
the host CPUID, not whatever KVM CPUID emulation makes up.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ