Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp783596rwb; Thu, 1 Dec 2022 08:18:57 -0800 (PST) X-Google-Smtp-Source: AA0mqf4Fb3PEpteNRzoOLjCGK3symAdkHGP6IQylnc7dezMhkEwxjtDcx4j6mdSmWEBlZO9Lb9MI X-Received: by 2002:a17:906:94d6:b0:7bd:3a3d:804e with SMTP id d22-20020a17090694d600b007bd3a3d804emr25661161ejy.701.1669911536945; Thu, 01 Dec 2022 08:18:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669911536; cv=none; d=google.com; s=arc-20160816; b=dWJfBqE758NTAlrf5Ot874V4gQj/VfMs8AJigowbDsvGKtinH+VNvUSg835HTHIYOR U1kv3seqHexoYMmhJST8M9IqHQmsTMkcdX1pWD4dQhiqB1dxpwFykl0uGnrop1SGOiay onNR3eUFRD+dxIZx7m45XTwKgstHxEWHlPk8zNil6a71xHzl26uIcZIJwl6A+YZgqfB8 QZl+29QdejKrSh5gqyf1a2n6G7klCfEDkVWJCIJ1n/Z+rKBcIdrDQGc9v01IWfyMT33P nB0SMzs/rwW/ne3uX4s2O4mizHFob0Xs870NViOWf9fKdDJKeX1W6JSNQk3Clxk+Q/bF nnxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:dkim-signature; bh=uICPaEENN8EB00poBiDynBWP9unBSRZ6Eo0ZeloiILw=; b=tVTTKJ9c7CDfHQ24gK0H283TgUwx4Pw6Qmr8pvMN+rgOqqC+EKYiTs+Brz7sjxU+5K TeiZmN/RnVXc0kuR3my+gQE49tY8nVv4GRUKhAV7cNndO4pUn5CXCwZ0IXa2aZ2GRH9z pfFcxcW49tRJQBi8x+ecMMqEDyv5lFJywuHkM/YvmvJDt9tRvkvHr4j+7yT/VOnyPvnC oVliiAkJBKLSB88jO2jJzbtwz/ecm38j6QpSNA+UDsWyyab35Cv2mItPruUjgIjHaFut aR/zEl9oVcgMpJYuCLvXCCyhNncWN/0gmqSBbTE6jskpckRywAjtuVJI/MBn0TGsHJPt 9fug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=bZPqbKpX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id he18-20020a1709073d9200b00782e437a368si4151475ejc.160.2022.12.01.08.18.35; Thu, 01 Dec 2022 08:18:56 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=bZPqbKpX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230457AbiLAPoD (ORCPT + 82 others); Thu, 1 Dec 2022 10:44:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57602 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229629AbiLAPoB (ORCPT ); Thu, 1 Dec 2022 10:44:01 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 77309EBC for ; Thu, 1 Dec 2022 07:43:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1669909385; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uICPaEENN8EB00poBiDynBWP9unBSRZ6Eo0ZeloiILw=; b=bZPqbKpXkw8CORJxhKbwJjDJvs67eWWzMvCIb/sHoBy8T2ipaFS4WJ6h7fROZj/4Ka0vQe L0HUUUnXt0ZKPKvwRR1kll1kXDTEpeNDK9ysVxX9NUl6bn9JoBjEpJWQ2OKZqPkzAAStUX A3xCjozhkLshFICkhtvfnQ17Ine/NvI= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-194-l_YDKHfWOTykhx4zFagU6w-1; Thu, 01 Dec 2022 10:43:03 -0500 X-MC-Unique: l_YDKHfWOTykhx4zFagU6w-1 Received: by mail-wr1-f71.google.com with SMTP id o10-20020adfa10a000000b00241f603af8dso536756wro.11 for ; Thu, 01 Dec 2022 07:43:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=uICPaEENN8EB00poBiDynBWP9unBSRZ6Eo0ZeloiILw=; b=XDFqBmo971+1As/jYkrwaCiKO/i+npACF8t4iNEdkKyjdMSzGTHknnuuf7BoQaGhHq K8o5NfReNGSbGfPPL0+om+UpWMvPOCP3T3/Hns4+yMX6exCqwZ5kSIoWYVWahWSabZhP IHXjFuue+EV8T+zkm2st7tFcaiU1BxhYVMAinUC5uaVpnfm7dofgmi0K73kvEw9X2rcR z3ZEfZL7jg5bcS8bZ0lGzhIUynzzG70U6MIG68XNqdEbI/2MvGv+1F594U7OeOw7TQ6Y CJzcgjje0drXOtAPzmSTKwIIBXMVUGtAgDDnQ54S+Ma3Oc8zOQdAX/ZbnbeE3hrUo6Gf G+uw== X-Gm-Message-State: ANoB5pnGDRrRaiCVUtVbdXpiALz8wrn+KSjpiIhytH9YQwwK0wqgyxTh S4CcvcNrZ0/RWJO53YWl5nZ7KRN0qz3MsrdrvpZCKuqA6F3x8XqyujSytvq1+WPAkZJLkkb1Ld4 WpHcrbsHNwG8k+kdJYYSu1Iw6 X-Received: by 2002:adf:ecd2:0:b0:236:6fd9:9efa with SMTP id s18-20020adfecd2000000b002366fd99efamr39370646wro.101.1669909382062; Thu, 01 Dec 2022 07:43:02 -0800 (PST) X-Received: by 2002:adf:ecd2:0:b0:236:6fd9:9efa with SMTP id s18-20020adfecd2000000b002366fd99efamr39370625wro.101.1669909381800; Thu, 01 Dec 2022 07:43:01 -0800 (PST) Received: from ovpn-194-141.brq.redhat.com (nat-2.ign.cz. [91.219.240.2]) by smtp.gmail.com with ESMTPSA id bg28-20020a05600c3c9c00b003cfa3a12660sm9307122wmb.1.2022.12.01.07.42.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Dec 2022 07:43:00 -0800 (PST) From: Vitaly Kuznetsov To: Sean Christopherson Cc: James Morse , Alexandru Elisei , Suzuki K Poulose , Oliver Upton , Atish Patra , David Hildenbrand , kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, Yuan Yao , Cornelia Huck , Isaku Yamahata , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Fabiano Rosas , Michael Ellerman , Kai Huang , Chao Gao , Thomas Gleixner , Paolo Bonzini , Marc Zyngier , Huacai Chen , Aleksandar Markovic , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Christian Borntraeger , Janosch Frank , Claudio Imbrenda , Matthew Rosato , Eric Farman , Sean Christopherson , David Woodhouse , Paul Durrant Subject: Re: [PATCH v2 10/50] KVM: VMX: Reset eVMCS controls in VP assist page during hardware disabling In-Reply-To: <20221130230934.1014142-11-seanjc@google.com> References: <20221130230934.1014142-1-seanjc@google.com> <20221130230934.1014142-11-seanjc@google.com> Date: Thu, 01 Dec 2022 16:42:58 +0100 Message-ID: <87h6yff7ul.fsf@ovpn-194-141.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=unavailable 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: X-Mailing-List: linux-kernel@vger.kernel.org Sean Christopherson writes: > Reset the eVMCS controls in the per-CPU VP assist page during hardware > disabling instead of waiting until kvm-intel's module exit. The controls > are activated if and only if KVM creates a VM, i.e. don't need to be > reset if hardware is never enabled. > > Doing the reset during hardware disabling will naturally fix a potential > NULL pointer deref bug once KVM disables CPU hotplug while enabling and > disabling hardware (which is necessary to fix a variety of bugs). If the > kernel is running as the root partition, the VP assist page is unmapped > during CPU hot unplug, and so KVM's clearing of the eVMCS controls needs > to occur with CPU hot(un)plug disabled, otherwise KVM could attempt to > write to a CPU's VP assist page after it's unmapped. > > Reported-by: Vitaly Kuznetsov > Signed-off-by: Sean Christopherson > --- > arch/x86/kvm/vmx/vmx.c | 50 +++++++++++++++++++++++++----------------- > 1 file changed, 30 insertions(+), 20 deletions(-) > > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c > index cea8c07f5229..d85d175dca70 100644 > --- a/arch/x86/kvm/vmx/vmx.c > +++ b/arch/x86/kvm/vmx/vmx.c > @@ -551,6 +551,33 @@ static int hv_enable_l2_tlb_flush(struct kvm_vcpu *vcpu) > return 0; > } > > +static void hv_reset_evmcs(void) > +{ > + struct hv_vp_assist_page *vp_ap; > + > + if (!static_branch_unlikely(&enable_evmcs)) > + return; > + > + /* > + * KVM should enable eVMCS if and only if all CPUs have a VP assist > + * page, and should reject CPU onlining if eVMCS is enabled the CPU > + * doesn't have a VP assist page allocated. > + */ > + vp_ap = hv_get_vp_assist_page(smp_processor_id()); > + if (WARN_ON_ONCE(!vp_ap)) > + return; > + In case my understanding is correct, this may actually get triggered for Hyper-V root partition: vmx_hardware_disable() gets called from kvm_dying_cpu() which has its own CPUHP_AP_KVM_STARTING stage. VP page unmapping happens in hv_cpu_die() which uses generic CPUHP_AP_ONLINE_DYN (happens first on CPU oflining AFAIR). I believe we need to introduce a new CPUHP_AP_HYPERV_STARTING stage and put it before CPUHP_AP_KVM_STARTING so it happens after it upon offlining. The issue is likely theoretical as Hyper-V root partition is a very special case, I'm not sure whether KVM is used there and whether CPU offlining is possible. In any case, WARN_ON_ONCE() is much better than NULL pointer dereference we have now :-) > + /* > + * Reset everything to support using non-enlightened VMCS access later > + * (e.g. when we reload the module with enlightened_vmcs=0) > + */ > + vp_ap->nested_control.features.directhypercall = 0; > + vp_ap->current_nested_vmcs = 0; > + vp_ap->enlighten_vmentry = 0; > +} > + > +#else /* IS_ENABLED(CONFIG_HYPERV) */ > +static void hv_reset_evmcs(void) {} > #endif /* IS_ENABLED(CONFIG_HYPERV) */ > > /* > @@ -2496,6 +2523,8 @@ static void vmx_hardware_disable(void) > if (cpu_vmxoff()) > kvm_spurious_fault(); > > + hv_reset_evmcs(); > + > intel_pt_handle_vmx(0); > } > > @@ -8462,27 +8491,8 @@ static void vmx_exit(void) > kvm_exit(); > > #if IS_ENABLED(CONFIG_HYPERV) > - if (static_branch_unlikely(&enable_evmcs)) { > - int cpu; > - struct hv_vp_assist_page *vp_ap; > - /* > - * Reset everything to support using non-enlightened VMCS > - * access later (e.g. when we reload the module with > - * enlightened_vmcs=0) > - */ > - for_each_online_cpu(cpu) { > - vp_ap = hv_get_vp_assist_page(cpu); > - > - if (!vp_ap) > - continue; > - > - vp_ap->nested_control.features.directhypercall = 0; > - vp_ap->current_nested_vmcs = 0; > - vp_ap->enlighten_vmentry = 0; > - } > - > + if (static_branch_unlikely(&enable_evmcs)) > static_branch_disable(&enable_evmcs); > - } > #endif > vmx_cleanup_l1d_flush(); Reviewed-by: Vitaly Kuznetsov -- Vitaly