From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: ARC-Seal: i=1; a=rsa-sha256; t=1517271810; cv=none; d=google.com; s=arc-20160816; b=QwsYijEPJyB6P2uoBsKgbfVAmZ4i3dSLnbnsFZw93A+JEeaIiskY2nnLvqlwJxsyG5 b4tfirXJD1UOyJrikqpz8t7s7bhWQFWrKIhJ3DJlf8g4k/8z5poQ07iGdizAqFFXG3Jm FrGtOzOG4dPuDkB8q/A9ts3Be3IhiYXk+He5VCdv5Oiuu2RKJzCjmReNt3CZ5cSgB+DF Xnz1lloHil4/uOWdKE1SAHUnyGM7BzCAa7YUzza3xklNVgeY0vMYoG6u8dXfTCPEMr5Z t0D0p89ML1yrcFK/NlkppvUkLxUcDyk6h8DQEQtCIZDPqtORozSL/GgMfivW42e40jJH VnVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:references:in-reply-to:sender :mime-version:dkim-signature:arc-authentication-results; bh=dTWEETC8n1HLBXNDPduY7SQvo0SOvBP720bORgy0Ba8=; b=fOmPHZ0nuCz7DQz6JQpCw0n334Cmjn9vHqE5UHZ0jbY4yK2xFdsvA37ZkrXEvN2Upv 9Ai4XHWvRuN+WjcnJwrczawGAD7ZVH7LKNjQtvkEoXo3bX+qoRSk71eFQL23iJ8kvhEP QaWqU8fc1MY9qUNiNU+TPfi/euv16WA68lSg1QRE3uYB/e0XKfqTVXRiatEzGrK54jt5 nU/FPvOyLDAEhqeAt3p3xioHMCVeNtS5Pm0rj0PL1pozmpeIxtDznoK3VgzvpMp9dMeI 0Kq+jPskovL7e4/fhF++H8X3DsHTye4DISfikhS00ORVfNfNOnA80qD50YPUviBjJHZ9 eigA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Wr+MlbLd; spf=pass (google.com: domain of linus971@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=linus971@gmail.com Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Wr+MlbLd; spf=pass (google.com: domain of linus971@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=linus971@gmail.com X-Google-Smtp-Source: AH8x226/0zDno+S7w7LM074DCJCcRppTy7d52c1CR20rACxTDTkFC8OgISk19xvV2Zxts6O+CS6mKkq/R2HjzV79fjU= MIME-Version: 1.0 Sender: linus971@gmail.com In-Reply-To: <1517259759.18619.38.camel@infradead.org> References: <1516476182-5153-6-git-send-email-karahmed@amazon.de> <20180129201404.GA1588@localhost.localdomain> <1517257022.18619.30.camel@infradead.org> <20180129204256.GV25150@localhost.localdomain> <31415b7f-9c76-c102-86cd-6bf4e23e3aee@linux.intel.com> <1517259759.18619.38.camel@infradead.org> From: Linus Torvalds Date: Mon, 29 Jan 2018 16:23:28 -0800 X-Google-Sender-Auth: wxfEIZLPZ7SdUPZSzGTN7iTFFgI Message-ID: Subject: Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure To: David Woodhouse Cc: Arjan van de Ven , Eduardo Habkost , KarimAllah Ahmed , Linux Kernel Mailing List , Andi Kleen , Andrea Arcangeli , Andy Lutomirski , Ashok Raj , Asit Mallick , Borislav Petkov , Dan Williams , Dave Hansen , Greg Kroah-Hartman , "H . Peter Anvin" , Ingo Molnar , Janakarajan Natarajan , Joerg Roedel , Jun Nakajima , Laura Abbott , Masami Hiramatsu , Paolo Bonzini , Peter Zijlstra , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Thomas Gleixner , Tim Chen , Tom Lendacky , KVM list , "the arch/x86 maintainers" , "Dr. David Alan Gilbert" Content-Type: text/plain; charset="UTF-8" X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590140581449802182?= X-GMAIL-MSGID: =?utf-8?q?1590974805691036446?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Mon, Jan 29, 2018 at 1:02 PM, David Woodhouse 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure Date: Mon, 29 Jan 2018 16:23:28 -0800 Message-ID: References: <1516476182-5153-6-git-send-email-karahmed@amazon.de> <20180129201404.GA1588@localhost.localdomain> <1517257022.18619.30.camel@infradead.org> <20180129204256.GV25150@localhost.localdomain> <31415b7f-9c76-c102-86cd-6bf4e23e3aee@linux.intel.com> <1517259759.18619.38.camel@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: Arjan van de Ven , Eduardo Habkost , KarimAllah Ahmed , Linux Kernel Mailing List , Andi Kleen , Andrea Arcangeli , Andy Lutomirski , Ashok Raj , Asit Mallick , Borislav Petkov , Dan Williams , Dave Hansen , Greg Kroah-Hartman , "H . Peter Anvin" , Ingo Molnar , Janakarajan Natarajan , Joerg Roedel , Jun Nakajima , Laura Abbott , Masami To: David Woodhouse Return-path: In-Reply-To: <1517259759.18619.38.camel@infradead.org> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Mon, Jan 29, 2018 at 1:02 PM, David Woodhouse 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