Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Zhang, Chen" <chen.zhang@intel.com>
To:     "Christopherson,, Sean" <seanjc@google.com>,
        "Gao, Chao" <chao.gao@intel.com>
CC:     "x86@kernel.org" <x86@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Borislav Petkov <bp@alien8.de>, Ingo Molnar <mingo@redhat.com>,
        Thomas Gleixner <tglx@linutronix.de>
Subject: RE: [RFC PATCH 5/9] x86/bugs: Use Virtual MSRs to request hardware
 mitigations
Thread-Topic: [RFC PATCH 5/9] x86/bugs: Use Virtual MSRs to request hardware
 mitigations
Thread-Index: AQHZDLMhDxurDeM6YkqaqujyHlpxN65t2QCAgAdw3ACAADdPAIABV2sAgAN1XoCAHT6AkA==
Date:   Tue, 10 Jan 2023 09:26:44 +0000
Message-ID: <MWHPR11MB00310B41B2F2681811D2DBD79BFF9@MWHPR11MB0031.namprd11.prod.outlook.com>
References: <20221210160046.2608762-1-chen.zhang@intel.com>
 <20221210160046.2608762-6-chen.zhang@intel.com> <Y5oviY0471JytWPo@google.com>
 <Y6BtcutjgcgE8dsv@gao-cwp> <Y6Cb2OrkQ8X3IvW5@google.com>
 <Y6G77CTIk8CvtTLn@gao-cwp> <Y6Sin1bmLN10yvMw@google.com>
In-Reply-To: <Y6Sin1bmLN10yvMw@google.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?T9m1rChSLy9bkk95vGPt4jwbDqaQuhBOhnauXvZuvAFs27aFPhOS2RatGvBb?=
 =?us-ascii?Q?MIW50zOE1j6GErmv39Dzds5Mvgu1VQpL9QT1uDxLYckTdaGzddQ/yQ0g7lJq?=
 =?us-ascii?Q?sfslb9tb6qd6SbSrTzxLg+8mnV7qrQQPNez/h51txommI+PXDt0Yk0Cep1St?=
 =?us-ascii?Q?W+y6ZBIILKGAToAQV/IJygDxK03n9QVMZvXhpSQ0xf/2ADmmMO4eoiauskAL?=
 =?us-ascii?Q?vUJf1eKoQLR5UmiezV9ruPv736Y1pnn+Lc/MQjCzf+KH9SGEzqvkJS536HQH?=
 =?us-ascii?Q?K93soTEGMPl7AMlod6KK90iSYiJ3UNEFwjgcieyfqVZpCxZFY2ADXe4GRJ7J?=
 =?us-ascii?Q?BFFfqRakEaEGRJ1UNtWJ3EYMjBWxtlKMqtUSYKfxqNA7OEqNKs7oeIA670pt?=
 =?us-ascii?Q?XYuftiVvNlHMPUIO9gsPJqF2RqQqWSxsKuCsWjLr5JCUZLO7Dsb9GZlroHvZ?=
 =?us-ascii?Q?Z4T/LniwQLFA689nV64duVyhTbGJi8SDcpcL2O2GRo8BLrVKvBXe9IGGdzNJ?=
 =?us-ascii?Q?qla1JCGMVZVU0JE41OpdTqdBP54fj8Rvlpp8Ia6ijjfqYRJK2sGRPxAFD0OP?=
 =?us-ascii?Q?ZzllAraH8U5Wv+a+XPPtNzSS9rIIlYglwao93S3OCEdGVEUR1dy18YMhxsyU?=
 =?us-ascii?Q?fNFWdBFcXzjDYOl6lEE9dvSqWHIZMYxecOs7PJdizOOZPzuvj+cCJh86+oqX?=
 =?us-ascii?Q?LVm9Qq10tIh/yUNxNyJtTpbO8SPYp79LvXFS23dBajABvq/mzHCMX5vmFFcz?=
 =?us-ascii?Q?bvGRiJ4xmAOmvqIuNkSjuXkiUjXANjVJbF5fGpegDjklAzjobgMO3xNgcvPt?=
 =?us-ascii?Q?HxHy9gzoDAwKTsY8OQQSH7jIxun9saQKVanaJ/93Rdw5uDaqLpm29cOzD2BK?=
 =?us-ascii?Q?trWJrkecxkfDTj1mCVnPCbGkHRK5WSOgIskJukGQDA0ie9B9EZlqvBuotEes?=
 =?us-ascii?Q?8c/P2Hc/zSlOSJXDrwzStKJcTgxsqQistloDxjdkvHoRuacA8RG7iA25NMGu?=
 =?us-ascii?Q?Jxv71XKgOBW8Mbp9Z5m+poUWfNVnTodKYsxdT/VUcwJguzLUaX8tTNAn4GR+?=
 =?us-ascii?Q?kTNyE+P8MH+cl0NlgDWA5L+Tw0DeuKImxMMjqtCkfV+IvfwBvKpPO9LDNaEn?=
 =?us-ascii?Q?/CAc61pPWi9z4g9aG1aPxYZhMN1jtLO3AM3/VgFhO3FTcxFT8zohWlHd39FT?=
 =?us-ascii?Q?EzwC/DA6rkl525YXbagEhVG8RLO1h5qsPyFAH07cOUsZkQBAuzFyjwOnprYU?=
 =?us-ascii?Q?ApaBeJFAQK39PaoDoRwginxrGuAwoNcksuc8ESQtSexcQqx3hns3Ccc16Lx2?=
 =?us-ascii?Q?lf0hW0mxKxkhxSBUAl3IRDo1HLkV4m683w+cqDiSU5BOZ0IF7S6FWQjZR/yo?=
 =?us-ascii?Q?X/xFzV2Fcgril/EXhkPMPGTa/dk8mNmVXhvFn0P22V/HAfLTIQdhaRBBEcUq?=
 =?us-ascii?Q?NdcI/jxUNW5ovtsMKuB3KLo9ywW/Ij7iXvIqr8zXpqlLdTFnc+qB6CQ3c95R?=
 =?us-ascii?Q?XtZ/xWgZyDXh+ka5vPT0pWbJo3s7M9MG0HBJL3Gvfq/eGSUVmcK6u4U5P1hP?=
 =?us-ascii?Q?09OloBgGO3QL5/In9mra0xnQgGC2W95Ya5HmIeoN?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB0031.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 41f5db90-b487-4abf-129e-08daf2ecca87
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2023 09:26:44.9618
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: cItGtOC6Kj1f27r3u/mbnSoRbK/K3Iuf1B4vIKW10wyFsX2T/HKF9N90CkPaHWDkRVOv1FIrFd6dETwbQoIQNw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR11MB4605
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> -----Original Message-----
> From: Sean Christopherson <seanjc@google.com>
> Sent: Friday, December 23, 2022 2:32 AM
> To: Gao, Chao <chao.gao@intel.com>
> Cc: Zhang, Chen <chen.zhang@intel.com>; x86@kernel.org; linux-
> kernel@vger.kernel.org; kvm@vger.kernel.org; Pawan Gupta
> <pawan.kumar.gupta@linux.intel.com>; Paolo Bonzini
> <pbonzini@redhat.com>; H. Peter Anvin <hpa@zytor.com>; Dave Hansen
> <dave.hansen@linux.intel.com>; Borislav Petkov <bp@alien8.de>; Ingo
> Molnar <mingo@redhat.com>; Thomas Gleixner <tglx@linutronix.de>
> Subject: Re: [RFC PATCH 5/9] x86/bugs: Use Virtual MSRs to request hardwa=
re
> mitigations
>=20
> On Tue, Dec 20, 2022, Chao Gao wrote:
> > On Mon, Dec 19, 2022 at 05:14:00PM +0000, Sean Christopherson wrote:
> > >On Mon, Dec 19, 2022, Chao Gao wrote:
> > >> On Wed, Dec 14, 2022 at 08:18:17PM +0000, Sean Christopherson wrote:
> > >> > To me, this looks like Intel is foisting a paravirt interface on
> > >> > KVM and other hypervisors without collaborating with said hypervis=
ors'
> developers and maintainers.
> > >> >
> > >> >I get that some of the mitigations are vendor specific, but things
> > >> >like RETPOLINE aren't vendor specific.  I haven't followed all of
> > >> >the mitigation stuff very closely, but I wouldn't be surprised if
> > >> >there are mitigations now or in the future that are common across
> > >> >architectures, e.g. arm64 and x86-64.  Intel doing its own thing
> > >> >means AMD and arm64 will likely follow suit, and suddenly KVM is
> > >> >supporting multiple paravirt interfaces for very similar things, wi=
thout
> having any control over the APIs.  That's all kinds of backwards.
> > >>
> > >> But if the interface is defined by KVM rather than Intel, it will
> > >> likely end up with different interfaces for different VMMs, then
> > >> Linux guest needs to support all of them. And KVM needs to
> > >> implement Hyper-V's and Xen's interface to support Hyper-V
> > >> enlightened and Xen enlightened guest. This is a _real_ problem and
> complicates KVM/Linux in a similar way as multiple paravirt interfaces.
> > >
> > >I never said the PV interfaces should be defined by KVM.  I 100%
> > >agree that any one hypervisor defining its own interface will suffer t=
he same
> problem.
> >
> > I am thinking there are only two options:
> >
> > 1. Intel defines the interface.
> > 2. Every VMM defines its own interface.
> >
> > Any middle ground between the two options?
>=20
> Work with other x86 hardware vendors to define a common interface?  Ask
> hypervisor developers to define a common, extensible interface?
>=20
> Maybe it turns out that it's impossible to abstract anything away and
> everything ends up being vendor-specific anyways, but not even trying to
> provide a common interace is extremely frustrating, especially since all =
this
> mitigation stuff has been going on for ~5 years.  There's been plenty of =
time to
> establish relationships and points of contact.
>=20
> > >I think having a PV interface for coordinating mitigations between
> > >host and guest is a great idea.  What I don't like is tying the
> > >interface to "hardware" and defining
> >
> > Do you think something below is better than the intel-defined interface=
?
>=20
> No, KVM doing its own thing would only exacerbate the issue.

Hi Sean,

Rethink about it and synced with Chao, we didn't think of a better solution=
 than
Intel-defined interface. If you have no more suggestions/comments here,
please review the rest of patches from this series when you have time.
I will try to address comments and push this series to RFC V2.

Thanks
Chen

>=20
> > add a new KVM_CAP_* and a KVM_FEATURE_* in hypervisor CPUID leaf to
> > enumerate the interface. And add a new virtual MSR 0x4b564dxx for
> > guest to report in-use software mitigations and assign one bit for
> > each software mitigation. On MSR write emulation, call into vmx code
> > to enable some hardware mitigations if the corresponding software
> mitigations are not effective on host.
> >
> > I am afraid it is late to switch to above approach because e.g., if
> > Hyper-V decides to support the intel-defined interface, KVM probably
> > needs to support it for Hyper-V guests.
>=20
> Hence my frustration.