Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Jon Kohler <jon@nutanix.com>
To:     Venkatesh Srinivas <venkateshs@chromium.org>
CC:     Jon Kohler <jon@nutanix.com>, Paolo Bonzini <pbonzini@redhat.com>,
        Sean Christopherson <seanjc@google.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Wanpeng Li <wanpengli@tencent.com>,
        Jim Mattson <jmattson@google.com>,
        Joerg Roedel <joro@8bytes.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        "x86@kernel.org" <x86@kernel.org>,
        "H. Peter Anvin" <hpa@zytor.com>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] KVM: x86: use X86_FEATURE_RSB_CTXSW for RSB stuffing in
 vmexit
Thread-Topic: [PATCH] KVM: x86: use X86_FEATURE_RSB_CTXSW for RSB stuffing in
 vmexit
Thread-Index: AQHXQ1KpTcM7v9elUEKaZTZTLSZ4qarYRHKAgAAGz4A=
Date:   Fri, 7 May 2021 17:46:47 +0000
Message-ID: <1D930225-038A-41F7-B88F-137B798B9AEA@nutanix.com>
References: <20210507150636.94389-1-jon@nutanix.com>
 <CAA0tLEoyy_ogDc11r_1T907Rp5CwgM64hFwRt5SX40THp2+C3A@mail.gmail.com>
In-Reply-To: <CAA0tLEoyy_ogDc11r_1T907Rp5CwgM64hFwRt5SX40THp2+C3A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?l1Dov3jkPe99+A7UZHlkIP1FuPbk2X0XdbNvgSHQVr9gbu9US5mgNKDpNSno?=
 =?us-ascii?Q?PCV0nUu1wbdF6B/4r/9Ll7jgwEmokdX6DTkUeucZYWl7/Bjo8vV49y0N0m8E?=
 =?us-ascii?Q?GksnvrSCG78C2VsMzP3otqCJmncNX0xCTOUQOR3v1Tvy0YLf+Kf6Sh4oN6fM?=
 =?us-ascii?Q?WURY8kzvlxGnd8R7I/o69TFaBmLzaWBLpE7qjcgIH2SKzOqQ+56AGOWULoHL?=
 =?us-ascii?Q?XnmemICib8dtwKCWOq8skzUCDrwHeNkDgdRvUEIYZmhyH2YOwryrcDK+bxvI?=
 =?us-ascii?Q?Z7K1r186IFQYcBrew5i/i29DpQO6lNp8ZdNPf21PXlyBan8uoBPxthC0CKj7?=
 =?us-ascii?Q?SNp2tuFUhAu3O6vv4mS4MNISTMKyLOdfixnIT5FLdkXkbqy1uYyylof15bK/?=
 =?us-ascii?Q?zY4VI2mbiSPfQ270hGhoFnk1IzFErMlS3GEImcS0XannzKeOgU/ftqukV/Hs?=
 =?us-ascii?Q?v9z0nmPq3l0OHNAsS8HQYWsIchP6hEFtaLjCFuQd9RX1we9VhGXnpca1pj2D?=
 =?us-ascii?Q?1o42iyhkpwtYQ3DhOShy1XvcnH6xeSdYsy4XfjN96q8HoePblJ/OEomLREFr?=
 =?us-ascii?Q?0YMIrRnCnw3NUAAWSyBOxJ2Z1dbMcZ0a6Pq49/mH0W5hsgP2/soqencyzHPn?=
 =?us-ascii?Q?XYVSPG2GjN1s94z2j03+3wjLs9UYtOOI3N0G9ttOqopPsnRcdbsVQ+Wazhaa?=
 =?us-ascii?Q?CWMn+1TjuCuT5jHn8i1u0piPC0RiZEecFvcyMuZNLudawkH0mfmkgU7AzEUC?=
 =?us-ascii?Q?pccfBwhV2LEtNvbI6y/zDCRyc2QVqjDovNld48BijNcpRV9OTXhhQzeLB250?=
 =?us-ascii?Q?6XNWZ9iuMopWvorKE5sPwzaRRMu1rOWHHXhbbRWK/qY5B4tbCu7avFvW/u97?=
 =?us-ascii?Q?QEBD2J8+V7foLxDBiaE0vVnFDLA43LANrLHeLSwiiJF0fiexEHv8Sbg3kY5M?=
 =?us-ascii?Q?zn9e1G4KRH+ydRUvJLdchJ51rVPTf0cuWusJg3mEwSQ0PHxPtYfJeVp5ifsW?=
 =?us-ascii?Q?QnzOMpAGyjbIPQrnUL0MpzfKq4O85u/mjw0HkWQBapaMc+8RD8e3rUrmiBeN?=
 =?us-ascii?Q?kWCMrCErd2xSnOPnzikjORyILpD8sqjPPyIv5UvDJAt5UsHzVMG36kYxLScn?=
 =?us-ascii?Q?Ae9OpKVXCmjBnePEU/ZuBhFVhF0s373PnKOmfOiTZQFg0fJq5PmZqowdngiv?=
 =?us-ascii?Q?EQWRLr+DR3/sWFCaF7gYD9sOPrinPt5ehBUct9VQptj28Yona6M8tQbGV9dy?=
 =?us-ascii?Q?UZvORnxaI3wrisBcfl95jqHlCm2GKDEoS6wFztpfa46eAQrBd67j0QMQQrjD?=
 =?us-ascii?Q?Ced9U6x57Qe0pdlbYllDTIADdoFisB/CFc/qCoh8kv1di1bWnRzU7xwBq1fN?=
 =?us-ascii?Q?BfOQ8rmj/KBqswm+F/UuNdMzNfkon+X75ZWcj9wtjGFpsbTmLQ=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <F4370B5716BE964685165BE08583917C@namprd02.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nutanix.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL0PR02MB4579.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1d1a852d-d106-4b2c-8afa-08d91180164d
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2021 17:46:47.6163
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bb047546-786f-4de1-bd75-24e5b6f79043
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: hZwvQS4bJb8BprJmvKdcvz7JdxsK07RtMSwn8qNv7a9LXe9EAw5YNKlUmUxEY4oeeGLZnuz0kttdMAazOH3yXovil/83Kniy1tR3dCOKC5c=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR02MB5377
X-Proofpoint-ORIG-GUID: 6CMmhJpo73V2_l-JUWn3tzVd8VwUP2k_
X-Proofpoint-GUID: 6CMmhJpo73V2_l-JUWn3tzVd8VwUP2k_
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761
 definitions=2021-05-07_06:2021-05-06,2021-05-07 signatures=0
X-Proofpoint-Spam-Reason: safe
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> On May 7, 2021, at 1:22 PM, Venkatesh Srinivas <venkateshs@chromium.org> =
wrote:
>=20
> On Fri, May 7, 2021 at 8:08 AM Jon Kohler <jon@nutanix.com> wrote:
>>=20
>> cpufeatures.h defines X86_FEATURE_RSB_CTXSW as "Fill RSB on context
>> switches" which seems more accurate than using X86_FEATURE_RETPOLINE
>> in the vmxexit path for RSB stuffing.
>>=20
>> X86_FEATURE_RSB_CTXSW is used for FILL_RETURN_BUFFER in
>> arch/x86/entry/entry_{32|64}.S. This change makes KVM vmx and svm
>> follow that same pattern. This pairs up nicely with the language in
>> bugs.c, where this cpu_cap is enabled, which indicates that RSB
>> stuffing should be unconditional with spectrev2 enabled.
>>        /*
>>         * If spectre v2 protection has been enabled, unconditionally fil=
l
>>         * RSB during a context switch; this protects against two indepen=
dent
>>         * issues:
>>         *
>>         *      - RSB underflow (and switch to BTB) on Skylake+
>>         *      - SpectreRSB variant of spectre v2 on X86_BUG_SPECTRE_V2 =
CPUs
>>         */
>>        setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
>>=20
>> Furthermore, on X86_FEATURE_IBRS_ENHANCED CPUs && SPECTRE_V2_CMD_AUTO,
>> we're bypassing setting X86_FEATURE_RETPOLINE, where as far as I could
>> find, we should still be doing RSB stuffing no matter what when
>> CONFIG_RETPOLINE is enabled and spectrev2 is set to auto.
>=20
> If I'm reading https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__sof=
tware.intel.com_security-2Dsoftware-2Dguidance_deep-2Ddives_deep-2Ddive-2Di=
ndirect-2Dbranch-2Drestricted-2Dspeculation&d=3DDwIBaQ&c=3Ds883GpUCOChKOHio=
cYtGcg&r=3DNGPRGGo37mQiSXgHKm5rCQ&m=3Ds8fqknrIuUa_jGbbihj0anypC4jz86QQ7UzzA=
op3B7k&s=3DoIcZtb8S_gcK5L1yzfPvinSHxjCCsx1PNn-imPMffKU&e=3D=20
> correctly, I don't think an RSB fill sequence is required on VMExit on
> processors w/ Enhanced IBRS. Specifically:
> """
> On processors with enhanced IBRS, an RSB overwrite sequence may not
> suffice to prevent the predicted target of a near return from using an
> RSB entry created in a less privileged predictor mode.  Software can
> prevent this by enabling SMEP (for transitions from user mode to
> supervisor mode) and by having IA32_SPEC_CTRL.IBRS set during VM exits
> """
> On Enhanced IBRS processors, it looks like SPEC_CTRL.IBRS is set
> across all #VMExits via x86_virt_spec_ctrl in kvm.
>=20
> So is this patch needed?
>=20
> Thanks,
> -- vs;

Venkatesh - Thanks for the reply. I read that the other way around, wherein
RSB overwrite still isn't good enough on eIBRS, so one would need to do all
three of the following to be in good shape:=20
a. RSB overwrite sequence
b. enable SMEP
c. toggle IA32_SPEC_CTRL.IBRS on vmexits=20

Said another way, the document reads like one would always need to do the
RSB overwrite sequence no matter what. Happy to hear if that is not the
case though, since RSB stuffing is a little expensive.

Note: I also checked the Intel SDM to see if perhaps there was something
there about this, but the document you linked is the only one I could
find on the topic.