Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Christophe de Dinechin <christophe.de.dinechin@gmail.com>
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Subject: Re: [RFC,05/10] x86/speculation: Add basic IBRS support
 infrastructure
In-Reply-To: <6a2713b1-74e7-53db-527d-d77cc4394f61@de.ibm.com>
Date:   Tue, 30 Jan 2018 15:56:17 +0100
Cc:     Christophe de Dinechin <christophe.de.dinechin@gmail.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        David Woodhouse <dwmw2@infradead.org>,
        Arjan van de Ven <arjan@linux.intel.com>,
        Eduardo Habkost <ehabkost@redhat.com>,
        KarimAllah Ahmed <karahmed@amazon.de>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Andi Kleen <ak@linux.intel.com>,
        Andrea Arcangeli <aarcange@redhat.com>,
        Andy Lutomirski <luto@kernel.org>,
        Ashok Raj <ashok.raj@intel.com>,
        Asit Mallick <asit.k.mallick@intel.com>,
        Borislav Petkov <bp@suse.de>,
        Dan Williams <dan.j.williams@intel.com>,
        Dave Hansen <dave.hansen@intel.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "H . Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
        Janakarajan Natarajan <Janakarajan.Natarajan@amd.com>,
        Joerg Roedel <joro@8bytes.org>,
        Jun Nakajima <jun.nakajima@intel.com>,
        Laura Abbott <labbott@redhat.com>,
        Masami Hiramatsu <mhiramat@kernel.org>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        =?utf-8?B?UmFkaW0gS3LEjW3DocWZ?= <rkrcmar@redhat.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Tim Chen <tim.c.chen@linux.intel.com>,
        Tom Lendacky <thomas.lendacky@amd.com>,
        KVM list <kvm@vger.kernel.org>,
        the arch/x86 maintainers <x86@kernel.org>,
        "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1C632B01-E0BC-4853-8CF3-4F4EDE800F8A@dinechin.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>
 <CA+55aFxBh3LvsQq9wy313NQCn3iu+yuAmsi0zNVxWmGDUUds-A@mail.gmail.com>
 <56a33b36-5568-5d6e-a858-3b22ea335bcb@de.ibm.com>
 <F3EF5343-C86F-4242-B254-20EF26BAB96C@dinechin.org>
 <6a2713b1-74e7-53db-527d-d77cc4394f61@de.ibm.com>
To:     Christian Borntraeger <borntraeger@de.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On 30 Jan 2018, at 15:52, Christian Borntraeger =
<borntraeger@de.ibm.com> wrote:
>=20
>=20
>=20
> On 01/30/2018 03:46 PM, Christophe de Dinechin wrote:
>>=20
>>=20
>>> On 30 Jan 2018, at 13:11, Christian Borntraeger =
<borntraeger@de.ibm.com> wrote:
>>>=20
>>>=20
>>>=20
>>> On 01/30/2018 01:23 AM, Linus Torvalds wrote:
>>> [...]
>>>>=20
>>>> 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.
>>>>=20
>>>> 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).
>>>>=20
>>>> 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?
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>>=20
>>>> Maybe that mystification comes from me missing something.
>>>=20
>>> I can only speak for KVM, but I think the hypervisor issues come =
from
>>> the fact that for migration purposes the hypervisor "lies" to the =
guest
>>> in regard to what kind of CPU is running.  (it has to lie, see =
below).
>>>=20
>>> This is to avoid random guest crashes by not announcing features. =
For
>>> example if you want to migrate forth and back between a system that
>>> has AVX512 and another one that has not you must tell the guest that
>>> AVX512 is not available - even if it runs on the capable system.
>>>=20
>>> To protect against new features the hypervisor only announces =
features
>>> that it understands.
>>> So you essentially start a VM in QEMU of a given CPU type that is
>>> constructed of a base cpu type plus extra features. Before =
migration,=20
>>> it is checked if  he target system can run a guest of given type -=20=

>>> otherwise migration is rejected.=20
>>>=20
>>> The management stack also knows things like baselining - basically
>>> creating the best possible guest CPU given a set of hosts.
>>>=20
>>> The problem now is: If you have lets say Broadwell and Skylakes.
>>> What kind of CPU type are you telling your guest? If you claim
>>> broadwell but run on skylake then you prevent that the guest can=20
>>> protect itself, because the guest does not know that it should do=20
>>> something special. If you say skylake the guest might start using
>>> features that broadwell does not understand.
>>=20
>> I believe that Linus=E2=80=99 question was whether it makes sense to =
defer
>> the entirety of the protection to the host kernel, although I was a =
bit
>> confused by his suggestion to always assume Skylake.
>>=20
>> In other words, is it safe enough to rely on the host kernel =
countermeasure
>> to protect guest kernels and their applications? In which case having
>> the guest believe it runs on Broadwell would not be that problematic.
>>=20
>> Aren=E2=80=99t there enough vmexits on the guest kernel context =
switch
>> to enforce protection on its behalf? Even if it=E2=80=99s
>>=20
>> a) some old kernel that without mitigation code
>>=20
>> or
>>=20
>> b) some new kernel that thinks it runs on an old CPU and disabled =
mitigation
>>=20
> I think it is not safe to just protect the host. CPU bound workload in =
the guest
> will switch a lot between guest user and guest kernel without =
triggering an
> exit.

But that=E2=80=99s only if the guest does not take any page faults. Is =
it possible to run any
of the known approaches to spectre and meltdown without ever faulting?
If the workload is not faulting, then it=E2=80=99s reading only stuff =
it=E2=80=99s allowed to, isn=E2=80=99t it?


Christophe