From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 03D42C4332F for ; Thu, 22 Dec 2022 18:32:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230271AbiLVScI (ORCPT ); Thu, 22 Dec 2022 13:32:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54772 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229704AbiLVScG (ORCPT ); Thu, 22 Dec 2022 13:32:06 -0500 Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 53F221A81F for ; Thu, 22 Dec 2022 10:32:04 -0800 (PST) Received: by mail-pj1-x1029.google.com with SMTP id gv5-20020a17090b11c500b00223f01c73c3so5970755pjb.0 for ; Thu, 22 Dec 2022 10:32:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=diDXt1oiDTYYx+8T5X5MAg+oSyu87V+IQcU8UuO/bT8=; b=Y1DXhnLRuVIKSL/hOJKfvpsDdGQDbEdO5M18e4MXIZPLXvz9VecS07A8CeqU+QzDV0 h98yaU63vhqQ3gkUN6YTnJc5rP5xMXXKl/pMBb30TRo+lWRCUYupW9uKxWaBUFya42rY jwyUiJxU8BAZ0FlPJOHRKyjnHkmNPSS7c7GA6uPuqdU6aSu54Zwp+jVfwPaz93PVrOqx w6gYl64rmL4KwTTqvT6iVSCYZP5Q1xzuIkuICJ+jo5Wc54WqehH8TMIn0HcQ+J7RmFU2 qeg2Q2fOQMOklkZCPOjnrt2bIDRvYiqmflDd1Kl8UEkRPEipw4/SbPwuFu0E0L8w15H0 lL2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=diDXt1oiDTYYx+8T5X5MAg+oSyu87V+IQcU8UuO/bT8=; b=iZoBWgTLH+zIMfeeEkkh23Tkh7IOI1UdH0jKOY5FaZewou5z/wMa2l+7MY20zfOLEs bcDVf6tkUVAnrjgBmNXAt0n9i90mYCPBZyEjx2twNVVwBXA6gR2xol87J0uCbbAw7Ll0 ed33oOdx2fXmL9i6N18jiamsKuJkE38AdzP+ttAT/5mtrkB8EEqAF/NwhEUYG8yCGqh5 kAfPIqYgr+rcSZHOtJ9Lwo+e3gWQd+pe3210aZ8EMfiSdSwioeNaTTuq4LsfsgbAvZpy 9rGVHSIrAvdhOdc9SySdUbTM9uuxG1mIEAlfA+3ryIQHeq18KxSBa+SiPE7D0FyTrr7I Jrgw== X-Gm-Message-State: AFqh2koV7eT2T2yhH483i2mgf2as4VDQ4L+LLVCsOJOF5oAg2GV8GKei KE9zZuWo2//6PqJrjwm2HzF3Zw== X-Google-Smtp-Source: AMrXdXuHe5bFWv9dlBVk/46Ykx3FR+o21ilS7idgRhcvRxes2Ivb3UoF23cHSQqTaY0zvEbur9DgIQ== X-Received: by 2002:a05:6a21:339a:b0:a7:891b:3601 with SMTP id yy26-20020a056a21339a00b000a7891b3601mr1406077pzb.1.1671733923687; Thu, 22 Dec 2022 10:32:03 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id w17-20020a170902e89100b00189ac5a2340sm860204plg.124.2022.12.22.10.32.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Dec 2022 10:32:03 -0800 (PST) Date: Thu, 22 Dec 2022 18:31:59 +0000 From: Sean Christopherson To: Chao Gao Cc: Zhang Chen , x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Pawan Gupta , Paolo Bonzini , "H. Peter Anvin" , Dave Hansen , Borislav Petkov , Ingo Molnar , Thomas Gleixner Subject: Re: [RFC PATCH 5/9] x86/bugs: Use Virtual MSRs to request hardware mitigations Message-ID: References: <20221210160046.2608762-1-chen.zhang@intel.com> <20221210160046.2608762-6-chen.zhang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 hypervisors' 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, without 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 the 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? Work with other x86 hardware vendors to define a common interface? Ask hypervisor developers to define a common, extensible interface? 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. > >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? No, KVM doing its own thing would only exacerbate the issue. > 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. Hence my frustration.