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:   Mon, 29 Jan 2018 16:23:28 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     David Woodhouse <dwmw2@...radead.org>
Cc:     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 Mon, Jan 29, 2018 at 1:02 PM, David Woodhouse <dwmw2@...radead.org> wrote:
>
> On Mon, 2018-01-29 at 12:44 -0800, Arjan van de Ven wrote:
>>
>> the objective is to have retpoline be safe everywhere and never use IBRS
>> (Linus was also pretty clear about that) so I'm confused by your question

Note on the unhappiness with some of the patches involved: what I do
*not* want to see is the "on every kernel entry" kind of garbage.

So my unhappiness with the intel microcode patches is two-fold:

 (a) the interface is nasty and wrong, and I absolutely detest how Intel did it.

 (b) the write to random MSR's on every kernel entry/exit is wrong

but that doesn't mean that I will necessarily end up NAK'ing every
single IBRS/IBPB patch.

My concern with (a) is that unlike meltdown, the intel work-around
isn't forward-looking, and doesn't have a "we fixed it" bit. Instead,
it has a "we have a nasty workaround that may or may not be horribly
expensive" bit, and isn't all that well-defined.

My dislike of (b) comes from "we have retpoline and various wondrous
RSB filling crud already, we're smarter than that". So it's not that I
refuse any IBRS/IBPB use, I refuse the stupid and _mindless_ kind of
use.

> The question is about all the additional RSB-frobbing and call depth
> counting and other bits that don't really even exist for Skylake yet in
> a coherent form.
>
> If a guest doesn't have those, because it's running some future kernel
> where they *are* implemented but not enabled because at *boot* time it
> discovered it wasn't on Skylake, the question is what happens if that
> guest is subsequently migrated to a Skylake-class machine.

So I actually have a _different_ question to the virtualization
people. This includes the vmware people, but it also obviously
incldues the Amazon AWS kind of usage.

When you're a hypervisor (whether vmware or Amazon), why do you even
end up caring about these things so much? You're protected from
meltdown thanks to the virtual environment already having separate
page tables.  And the "big hammer" approach to spectre would seem to
be to just make sure the BTB and RSB are flushed at vmexit time - and
even then you might decide that you really want to just move it to
vmenter time, and only do it if the VM has changed since last time
(per CPU).

Why do you even _care_ about the guest, and how it acts wrt Skylake?
What you should care about is not so much the guests (which do their
own thing) but protect guests from each other, no?

So I'm a bit mystified by some of this discussion within the context
of virtual machines. I think that is separate from any measures that
the guest machine may then decide to partake in.

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.

Maybe that mystification comes from me missing something.

               Linus