KVM: vmx/nested: avoid blindly setting SECONDARY_EXEC_ENCLS_EXITING when sgx is enabled
Message ID | 20221025123749.2201649-1-eesposit@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp980200wru; Tue, 25 Oct 2022 05:38:27 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4epzOrhI3mZ4h6z49ElT/wScNCDiqabhKJBwOTs8dx35o/khr8EInMarU8U5tiu2yoTyJM X-Received: by 2002:a17:90a:2cc7:b0:212:f074:cf4d with SMTP id n65-20020a17090a2cc700b00212f074cf4dmr17593935pjd.70.1666701507125; Tue, 25 Oct 2022 05:38:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666701507; cv=none; d=google.com; s=arc-20160816; b=VQfjEjN34cgllIOgEeoxngZ4Skr233u2qfWLUfrbfIium23d5+F8cBTjhv1+Nt5uxh h8DSdpJdMngj+NVrW3Qt11aNePVKvrtC5cEwu8b0C8ISNoXrB79rpgkvUYL5nSzoy5AP 3ur6NoSET2CsAD5fpQPvmiFnJSaEO2udGp6SmHafNSfAO0FULsWkvT8cXeHfQzlzgkF9 4Hs83cn6oiynt0tKEjDOD7J5eeHaBH9PjIhZzGiNzBii4InD0niSMd/RBHcddNKH6KJe 4zHtJcxmUUEX7qxjU7yanrBeYYiUiCN50fXtmV//cElvIRNEKmRhocYENkPy/mRXizey CgCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=boAr6JkR73ssS+S6gWh1SUDS3IyoLaLW/9nsvQotYJ4=; b=ZN08avxD0+Gzo+BCt5mG4fP67Wn2g+hNLZqkj0O67VhEDcTGcvipeJqMf1u1NHXoD/ siAvxy0fsE/duK1fCLulsEhRFw4IAZzz2/GfQWbm4BjxKCtz/NjSvglFCB2UxWLeiyEw p1p0NIoLB3qIhNhPokDqNTQC+TktKlCbm05hpMQn56F82FdC5Mlz3wY/dsO3xMe8Z6No 5W2j9gef41HHZQK6koPZRltGRMklzW5KQE8jMN56RHWfRODjwy2DDxcEVWK/h873jbVH i32ONpJXG1LzuDEDl60vsH69CL4qh+W867NGBd1CZMXAC52Xf2goWLyycbLKPz/l2bge 9qRA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Plw3PKLl; 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: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h187-20020a636cc4000000b0043a0121bb28si2540569pgc.811.2022.10.25.05.38.14; Tue, 25 Oct 2022 05:38:27 -0700 (PDT) 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=Plw3PKLl; 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 S231814AbiJYMh4 (ORCPT <rfc822;pwkd43@gmail.com> + 99 others); Tue, 25 Oct 2022 08:37:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56634 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230193AbiJYMhz (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 25 Oct 2022 08:37:55 -0400 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 51430188A89 for <linux-kernel@vger.kernel.org>; Tue, 25 Oct 2022 05:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666701473; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=boAr6JkR73ssS+S6gWh1SUDS3IyoLaLW/9nsvQotYJ4=; b=Plw3PKLlokhCzxUMkKXA8sRXvMhS/3v8eXwgNySrhWb+eEPAoOm396bh0jXFU/C4W7MBln 4LakJJs6fBVKj8cZO3XXuzi7mJlhGzaayFPiUWN4GtIfYbRixyjzIJAPVh53H9yjY4I/p6 ewYQH/sqrfG97f0i1EDb8AUsy9e8sno= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-470-QTzcfl6kMFSkPo91IvFfWQ-1; Tue, 25 Oct 2022 08:37:52 -0400 X-MC-Unique: QTzcfl6kMFSkPo91IvFfWQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id EE10D380671E; Tue, 25 Oct 2022 12:37:51 +0000 (UTC) Received: from virtlab701.virt.lab.eng.bos.redhat.com (virtlab701.virt.lab.eng.bos.redhat.com [10.19.152.228]) by smtp.corp.redhat.com (Postfix) with ESMTP id 737352166B2A; Tue, 25 Oct 2022 12:37:51 +0000 (UTC) From: Emanuele Giuseppe Esposito <eesposit@redhat.com> To: kvm@vger.kernel.org Cc: Sean Christopherson <seanjc@google.com>, Paolo Bonzini <pbonzini@redhat.com>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>, Bandan Das <bsd@redhat.com>, linux-kernel@vger.kernel.org, Emanuele Giuseppe Esposito <eesposit@redhat.com>, stable@vger.kernel.org Subject: [PATCH] KVM: vmx/nested: avoid blindly setting SECONDARY_EXEC_ENCLS_EXITING when sgx is enabled Date: Tue, 25 Oct 2022 08:37:49 -0400 Message-Id: <20221025123749.2201649-1-eesposit@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Spam-Status: No, score=-2.6 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=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 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747580257676184266?= X-GMAIL-MSGID: =?utf-8?q?1747663199626060390?= |
Series |
KVM: vmx/nested: avoid blindly setting SECONDARY_EXEC_ENCLS_EXITING when sgx is enabled
|
|
Commit Message
Emanuele Giuseppe Esposito
Oct. 25, 2022, 12:37 p.m. UTC
Currently vmx enables SECONDARY_EXEC_ENCLS_EXITING even when sgx
is not set in the host MSR.
When booting a guest, KVM checks that the cpuid bit is actually set
in vmx.c, and if not, it does not enable the feature.
However, in nesting this control bit is blindly set, and will be
propagated to VMCS12 and VMCS02. Therefore, when L1 tries to boot
the guest, the host will try to execute VMLOAD with VMCS02 containing
a feature that the hardware does not support, making it fail with
hardware error 0x7.
According to section "Secondary Processor-Based VM-Execution Controls"
in the Intel SDM, software should *always* check the value in the
actual MSR_IA32_VMX_PROCBASED_CTLS2 before enabling this bit.
Not updating enable_sgx is responsible for a second bug:
vmx_set_cpu_caps() doesn't clear the SGX bits when hardware support is
unavailable. This is a much less problematic bug as it only pops up
if SGX is soft-disabled (the case being handled by cpu_has_sgx()) or if
SGX is supported for bare metal but not in the VMCS (will never happen
when running on bare metal, but can theoertically happen when running in
a VM).
Last but not least, KVM should ideally have module params reflect KVM's
actual configuration.
RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=2127128
Fixes: 72add915fbd5 ("KVM: VMX: Enable SGX virtualization for SGX1, SGX2 and LC")
Cc: stable@vger.kernel.org
Suggested-by: Sean Christopherson <seanjc@google.com>
Suggested-by: Bandan Das <bsd@redhat.com>
Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
---
arch/x86/kvm/vmx/vmx.c | 5 +++++
1 file changed, 5 insertions(+)
Comments
Shortlog scope is still wrong, should be "KVM: nVMX:" The shortlog is also somewhat is misleading/confusing, as it's not at all obvious that "sgx enabled" means "KVM's sgx_module param is enabled" and not "SGX is enabled in the system". E.g. KVM: nVMX: Advertise ENCLS_EXITING to L1 iff SGX is fully supported On Tue, Oct 25, 2022, Emanuele Giuseppe Esposito wrote: > Currently vmx s/vmx/KVM > enables SECONDARY_EXEC_ENCLS_EXITING even when sgx is not set in the host MSR. "sgx is not set in the host MSR" is ambiguous. "sgx ... in the host MSR" could easily refer to the SGX_ENABLED bit in IA32_FEATURE_CONTROL, it could refer to the ENCLS_EXITING bit in the allowed-1 half of IA32_VMX_PROCBASED_CTLS2, etc... In other words, please be more precise. This statement is also wrong in that it implies that KVM _always_ sets ENCLS_EXITING, whereas the bug is purely limited to nested virtualization. E.g. Clear enable_sgx if ENCLS-exiting is not supported, i.e. if SGX cannot be virtualized. This fixes a bug where KVM would advertise ENCLS-exiting to L1 and propagate the control from vmcs12 to vmcs02 even if ENCLS-exiting isn't supported in secondary execution controls, e.g. because SGX isn't fully enabled, and thus induce an unexpected VM-Fail in L1. > When booting a guest, KVM checks that the cpuid bit is actually set > in vmx.c, and if not, it does not enable the feature. Again, this is nothing to do with the failure.
On 10/25/22 19:21, Sean Christopherson wrote: > Shortlog scope is still wrong, should be "KVM: nVMX:" > > The shortlog is also somewhat is misleading/confusing, as it's not at all obvious > that "sgx enabled" means "KVM's sgx_module param is enabled" and not "SGX is enabled > in the system". > > E.g. > > KVM: nVMX: Advertise ENCLS_EXITING to L1 iff SGX is fully supported Queued with this commit message: --- KVM: VMX: fully disable SGX if SECONDARY_EXEC_ENCLS_EXITING unavailable Clear enable_sgx if ENCLS-exiting is not supported, i.e. if SGX cannot be virtualized. When KVM is loaded, adjust_vmx_controls checks that the bit is available before enabling the feature; however, other parts of the code check enable_sgx and not clearing the variable caused two different bugs, mostly affecting nested virtualization scenarios. First, because enable_sgx remained true, SECONDARY_EXEC_ENCLS_EXITING would be marked available in the capability MSR that are accessed by a nested hypervisor. KVM would then propagate the control from vmcs12 to vmcs02 even if it isn't supported by the processor, thus causing an unexpected VM-Fail (exit code 0x7) in L1. Second, vmx_set_cpu_caps() would not clear the SGX bits when hardware support is unavailable. This is a much less problematic bug as it only happens if SGX is soft-disabled (available in the processor but hidden in CPUID) or if SGX is supported for bare metal but not in the VMCS (will never happen when running on bare metal, but can theoertically happen when running in a VM). Last but not least, this ensures that module params in sysfs reflect KVM's actual configuration. RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=2127128 Fixes: 72add915fbd5 ("KVM: VMX: Enable SGX virtualization for SGX1, SGX2 and LC") Cc: stable@vger.kernel.org Suggested-by: Sean Christopherson <seanjc@google.com> Suggested-by: Bandan Das <bsd@redhat.com> Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com> Message-Id: <20221025123749.2201649-1-eesposit@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> --- The bug is strictly speaking not in nVMX, although that's where most of the symptoms surface. Paolo
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index 9dba04b6b019..ea0c65d3c08a 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -8263,6 +8263,11 @@ static __init int hardware_setup(void) if (!cpu_has_virtual_nmis()) enable_vnmi = 0; + #ifdef CONFIG_X86_SGX_KVM + if (!cpu_has_vmx_encls_vmexit()) + enable_sgx = false; + #endif + /* * set_apic_access_page_addr() is used to reload apic access * page upon invalidation. No need to do anything if not