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;
Date:   Fri, 23 Feb 2018 13:12:37 -0500
From:   Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To:     Paolo Bonzini <pbonzini@redhat.com>
Cc:     "Van De Ven, Arjan" <arjan.van.de.ven@intel.com>,
        "valdis.kletnieks@vt.edu" <valdis.kletnieks@vt.edu>,
        Jon Masters <jcm@jonmasters.org>,
        David Woodhouse <dwmw2@infradead.org>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "x86@kernel.org" <x86@kernel.org>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "Hansen, Dave" <dave.hansen@intel.com>,
        Ingo Molnar <mingo@kernel.org>
Subject: Is: RSB Alternative bit in IA32_ARCH_CAPABILITIES Was:Re: [PATCH
 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs
Message-ID: <20180223181237.GA19321@char.us.oracle.com>
References: <1518776517.7876.21.camel@infradead.org>
 <d61edc94-8a51-62bd-65ed-8068451ca5b5@redhat.com>
 <1518783021.7876.34.camel@infradead.org>
 <4882860e-23c5-75b3-ac02-c700f615156e@jonmasters.org>
 <0575AF4FD06DD142AD198903C74E1CC87A61923C@ORSMSX103.amr.corp.intel.com>
 <10373.1519084385@turing-police.cc.vt.edu>
 <0575AF4FD06DD142AD198903C74E1CC87A619255@ORSMSX103.amr.corp.intel.com>
 <aa3fbaf1-0efc-64b1-4f7b-3d00b0493d48@redhat.com>
 <0575AF4FD06DD142AD198903C74E1CC87A619465@ORSMSX103.amr.corp.intel.com>
 <2159cdc0-c30d-3bf8-1c25-74bff46a1e91@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <2159cdc0-c30d-3bf8-1c25-74bff46a1e91@redhat.com>
User-Agent: Mutt/1.8.3 (2017-05-23)
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Feb 20, 2018 at 03:46:57PM +0100, Paolo Bonzini wrote:
> On 20/02/2018 15:08, Van De Ven, Arjan wrote:
> >>>> For bonus points:  What should happen to a VM that is live migrate=
d
> >>>> from one hypervisor to another, and the hypervisors have different
> >>>> IBRS support?
> >>>
> >>> Doctor Doctor it hurts when I do this....
> >>>
> >>> Migration tends to only work between HV's that are relatively
> >>> homogeneous, that's nothing new...
> >>
> >> No Arjan, this is just wrong.  Well, I suppose it's right in the pre=
sent
> >> tense with the IBRS mess on Skylake, but it's _not_ been true until =
last
> >> year.
> >=20
> > I meant software wise. You're not going to live migrate from xen to
> > kvm or backwards. or between very radically different versions of the
> > kvm stack.
>=20
> Forwards migration to a radically newer version certainly happens.  So
> when the source hypervisor was too old to tell the VM about IBRS_ALL,
> for example, migration should work properly and the VM should perform
> well on the destination hypervisor.

To add a bit more to this, Intel just updated their IA32_ARCH_CAPABILITIE=
S_MSR
to have a new bit to sample to figure out whether you need IBRS or not
during runtime.

See https://software.intel.com/sites/default/files/managed/1d/46/Retpolin=
e-A-Branch-Target-Injection-Mitigation.pdf
in 5.3
Virtual Machine CPU Identification:

"To remedy this situation, an operating system running as a VM can query =
bit 2 of the IA32_ARCH_CAPABILITIES MSR, known as =E2=80=9CRSB Alternate=E2=
=80=9D (RSBA). When RSBA is set, it indicates that the VM may run on a pr=
ocessor vulnerable to exploits of Empty RSB conditions regardless of the =
processor=E2=80=99s DisplayFamily/DisplayModel signature, and that the op=
erating system should deploy appropriate mitigations. Virtual machine man=
agers (VMM) may set RSBA via MSR interception to indicate that a virtual =
machine might run at some time in the future on a vulnerable processor."

New bit.. but not mentioned in the:

336996-Speculative-Execution-Side-Channel-Mitigations.pdf

Paolo, is there some form of callback inside of the guest when KVM guests=
 are migrated?
(It exists under Xen, but I don't see it under KVM?)
>=20
> Backwards migration to older hypervisors also happens sometimes, but in
> general it creates more userspace than kernel issues.
>=20
> Paolo