Message ID | 20221025124741.228045-1-mlevitsk@redhat.com |
---|---|
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 l7csp985503wru; Tue, 25 Oct 2022 05:50:47 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4AnZ9WE1altY0IA9FhS9bT7wdg3feNPH54lkGKwM1fG4T9bsAHH7Y0a1di48zjfeZislz9 X-Received: by 2002:a63:d202:0:b0:46f:930:ea56 with SMTP id a2-20020a63d202000000b0046f0930ea56mr9243620pgg.275.1666702247094; Tue, 25 Oct 2022 05:50:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666702247; cv=none; d=google.com; s=arc-20160816; b=J2ZOfhTVKqZP9uq7Mpc8hA4H8goiRLgk0A3CfBQvBSYJ4dfVePIYsD8E8gnUQWQVJw TBM/+OvMXCMjLhkx7rAenQTg0ACkrALwezofhjIs6Sso+o+DB0CIlBvVG2nnq5GnCVog a+6V2JoUO3oYsUEhtj6yQ6tfS+b8RbvVAQzBqB65Vbx80D9tOYcLGA3ZIKAxTEj+g2+l qa0p8G+vHYGCxul7BmaiX3QCfVNSQtwksfId4YrUb3TumGHo74QrDjlecTcN9LApR1Sx qFrGb1oQxZIp0STr/pTuAkRIM+KEK44IcSniz4a0LBdIZzaUrjvTbG1S7hWzJz0OBxR3 4keg== 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=YKqk8JFJPFyZT4uxuIdJDMrDXX3QslvogL56oEpKGVE=; b=pu88iEz3EakXfqvt4reB2LkYp0n93BfZPSqelZfdFtPevgiy4/LeMcZijIDKaoOQxy 5i9AvcfKBM3rh+tHh7KW0ZsBCzHlXgYd+1FepZRJFiVt/i8Zwy3zZjVzz9/UHRsbgOkp qu1UdzlflwkrMuubGbiJ4OggTH3K8jrMw70bwBvtBhgOg3/7UqKR2Ggctn00K5VpIN1e AIjR0pa7BSFif3BBgHRYiQXFNPnqJAciVAM8kFTZHNjkOTx8rKyQ5KCWlIY3UI0UUj8K nwz2YYeUy30Ep9fg7p7WYvr/JzVUdXozu8Sn3KZo11nhPaP9fkFLwO0W5tUZAOrdcJb5 InBA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=aGdtZjrw; 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 i4-20020a625404000000b0053abe946910si2551884pfb.349.2022.10.25.05.50.34; Tue, 25 Oct 2022 05:50:47 -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=aGdtZjrw; 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 S232240AbiJYMuQ (ORCPT <rfc822;pwkd43@gmail.com> + 99 others); Tue, 25 Oct 2022 08:50:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50660 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231664AbiJYMtq (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 25 Oct 2022 08:49:46 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B68DC18BE29 for <linux-kernel@vger.kernel.org>; Tue, 25 Oct 2022 05:48:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666702071; 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: content-transfer-encoding:content-transfer-encoding; bh=YKqk8JFJPFyZT4uxuIdJDMrDXX3QslvogL56oEpKGVE=; b=aGdtZjrwKLeHD5AYaBwW9VrYi5FU3ehFhs2g1OUfJx4yz+7uc3zwXrDzp1uTnZgeH8OSf5 ABWLPUzszUsAuhc+naPz2BeLVbMlUkfVce78edgE1RuUOYr7XihK9mdD3jvpOGLruNqa6V NXHzQHlBHHaJfAQnmzYHQBJwWUUkMwU= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-191-nkgboKVhNQ6gqyX7rFkv3A-1; Tue, 25 Oct 2022 08:47:47 -0400 X-MC-Unique: nkgboKVhNQ6gqyX7rFkv3A-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4C9F0857AA0; Tue, 25 Oct 2022 12:47:46 +0000 (UTC) Received: from amdlaptop.tlv.redhat.com (dhcp-4-238.tlv.redhat.com [10.35.4.238]) by smtp.corp.redhat.com (Postfix) with ESMTP id BD31E40C6EC6; Tue, 25 Oct 2022 12:47:42 +0000 (UTC) From: Maxim Levitsky <mlevitsk@redhat.com> To: kvm@vger.kernel.org Cc: Thomas Gleixner <tglx@linutronix.de>, Yang Zhong <yang.zhong@intel.com>, x86@kernel.org, Jim Mattson <jmattson@google.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, Sean Christopherson <seanjc@google.com>, Wanpeng Li <wanpengli@tencent.com>, Shuah Khan <shuah@kernel.org>, Guang Zeng <guang.zeng@intel.com>, Joerg Roedel <joro@8bytes.org>, Maxim Levitsky <mlevitsk@redhat.com>, linux-kernel@vger.kernel.org, Dave Hansen <dave.hansen@linux.intel.com>, Ingo Molnar <mingo@redhat.com>, linux-kselftest@vger.kernel.org, Kees Cook <keescook@chromium.org>, "H. Peter Anvin" <hpa@zytor.com>, Wei Wang <wei.w.wang@intel.com>, Borislav Petkov <bp@alien8.de> Subject: [PATCH RESEND v4 00/23] SMM emulation and interrupt shadow fixes Date: Tue, 25 Oct 2022 15:47:18 +0300 Message-Id: <20221025124741.228045-1-mlevitsk@redhat.com> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 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=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: <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?1747663617813524514?= X-GMAIL-MSGID: =?utf-8?q?1747663975503777392?= |
Series |
SMM emulation and interrupt shadow fixes
|
|
Message
Maxim Levitsky
Oct. 25, 2022, 12:47 p.m. UTC
This patch series is a result of long debug work to find out why sometimes guests with win11 secure boot were failing during boot. During writing a unit test I found another bug, turns out that on rsm emulation, if the rsm instruction was done in real or 32 bit mode, KVM would truncate the restored RIP to 32 bit. I also refactored the way we write SMRAM so it is easier now to understand what is going on. The main bug in this series which I fixed is that we allowed #SMI to happen during the STI interrupt shadow, and we did nothing to both reset it on #SMI handler entry and restore it on RSM. V4: - rebased on top of patch series from Paolo which allows smm support to be disabled by Kconfig option. - addressed review feedback. I included these patches in the series for reference. Best regards, Maxim Levitsky Maxim Levitsky (15): bug: introduce ASSERT_STRUCT_OFFSET KVM: x86: emulator: em_sysexit should update ctxt->mode KVM: x86: emulator: introduce emulator_recalc_and_set_mode KVM: x86: emulator: update the emulation mode after rsm KVM: x86: emulator: update the emulation mode after CR0 write KVM: x86: smm: number of GPRs in the SMRAM image depends on the image format KVM: x86: smm: check for failures on smm entry KVM: x86: smm: add structs for KVM's smram layout KVM: x86: smm: use smram structs in the common code KVM: x86: smm: use smram struct for 32 bit smram load/restore KVM: x86: smm: use smram struct for 64 bit smram load/restore KVM: svm: drop explicit return value of kvm_vcpu_map KVM: x86: SVM: use smram structs KVM: x86: SVM: don't save SVM state to SMRAM when VM is not long mode capable KVM: x86: smm: preserve interrupt shadow in SMRAM Paolo Bonzini (8): KVM: x86: start moving SMM-related functions to new files KVM: x86: move SMM entry to a new file KVM: x86: move SMM exit to a new file KVM: x86: do not go through ctxt->ops when emulating rsm KVM: allow compiling out SMM support KVM: x86: compile out vendor-specific code if SMM is disabled KVM: x86: remove SMRAM address space if SMM is not supported KVM: x86: do not define KVM_REQ_SMI if SMM disabled arch/x86/include/asm/kvm-x86-ops.h | 2 + arch/x86/include/asm/kvm_host.h | 29 +- arch/x86/kvm/Kconfig | 11 + arch/x86/kvm/Makefile | 1 + arch/x86/kvm/emulate.c | 458 +++---------- arch/x86/kvm/kvm_cache_regs.h | 5 - arch/x86/kvm/kvm_emulate.h | 47 +- arch/x86/kvm/lapic.c | 14 +- arch/x86/kvm/lapic.h | 7 +- arch/x86/kvm/mmu/mmu.c | 1 + arch/x86/kvm/smm.c | 637 ++++++++++++++++++ arch/x86/kvm/smm.h | 160 +++++ arch/x86/kvm/svm/nested.c | 3 + arch/x86/kvm/svm/svm.c | 43 +- arch/x86/kvm/vmx/nested.c | 1 + arch/x86/kvm/vmx/vmcs12.h | 5 +- arch/x86/kvm/vmx/vmx.c | 11 +- arch/x86/kvm/x86.c | 353 +--------- include/linux/build_bug.h | 9 + tools/testing/selftests/kvm/x86_64/smm_test.c | 2 + 20 files changed, 1031 insertions(+), 768 deletions(-) create mode 100644 arch/x86/kvm/smm.c create mode 100644 arch/x86/kvm/smm.h -- 2.34.3
Comments
On 10/25/22 14:47, Maxim Levitsky wrote: > This patch series is a result of long debug work to find out why > sometimes guests with win11 secure boot > were failing during boot. > > During writing a unit test I found another bug, turns out > that on rsm emulation, if the rsm instruction was done in real > or 32 bit mode, KVM would truncate the restored RIP to 32 bit. > > I also refactored the way we write SMRAM so it is easier > now to understand what is going on. > > The main bug in this series which I fixed is that we > allowed #SMI to happen during the STI interrupt shadow, > and we did nothing to both reset it on #SMI handler > entry and restore it on RSM. I have now sent out the final/new version of the first 8 patches and will review these tomorrow. Thanks for your patience. :) Paolo
On Thu, 2022-10-27 at 18:49 +0200, Paolo Bonzini wrote: > On 10/25/22 14:47, Maxim Levitsky wrote: > > This patch series is a result of long debug work to find out why > > sometimes guests with win11 secure boot > > were failing during boot. > > > > During writing a unit test I found another bug, turns out > > that on rsm emulation, if the rsm instruction was done in real > > or 32 bit mode, KVM would truncate the restored RIP to 32 bit. > > > > I also refactored the way we write SMRAM so it is easier > > now to understand what is going on. > > > > The main bug in this series which I fixed is that we > > allowed #SMI to happen during the STI interrupt shadow, > > and we did nothing to both reset it on #SMI handler > > entry and restore it on RSM. > > I have now sent out the final/new version of the first 8 patches and > will review these tomorrow. Thanks for your patience. :) > > Paolo > Thank you very much!! Best regards, Maxim Levitsky
On 10/27/22 19:06, Maxim Levitsky wrote: > On Thu, 2022-10-27 at 18:49 +0200, Paolo Bonzini wrote: >> On 10/25/22 14:47, Maxim Levitsky wrote: >>> This patch series is a result of long debug work to find out why >>> sometimes guests with win11 secure boot >>> were failing during boot. >>> >>> During writing a unit test I found another bug, turns out >>> that on rsm emulation, if the rsm instruction was done in real >>> or 32 bit mode, KVM would truncate the restored RIP to 32 bit. >>> >>> I also refactored the way we write SMRAM so it is easier >>> now to understand what is going on. >>> >>> The main bug in this series which I fixed is that we >>> allowed #SMI to happen during the STI interrupt shadow, >>> and we did nothing to both reset it on #SMI handler >>> entry and restore it on RSM. >> >> I have now sent out the final/new version of the first 8 patches and >> will review these tomorrow. Thanks for your patience. :) >> >> Paolo >> > Thank you very much!! Queued, thanks. Note that some emulator patches should go in stable releases so I have reordered them in front. Paolo
On Fri, Oct 28, 2022, Paolo Bonzini wrote: > On 10/27/22 19:06, Maxim Levitsky wrote: > > On Thu, 2022-10-27 at 18:49 +0200, Paolo Bonzini wrote: > > > On 10/25/22 14:47, Maxim Levitsky wrote: > > > > This patch series is a result of long debug work to find out why > > > > sometimes guests with win11 secure boot > > > > were failing during boot. > > > > > > > > During writing a unit test I found another bug, turns out > > > > that on rsm emulation, if the rsm instruction was done in real > > > > or 32 bit mode, KVM would truncate the restored RIP to 32 bit. > > > > > > > > I also refactored the way we write SMRAM so it is easier > > > > now to understand what is going on. > > > > > > > > The main bug in this series which I fixed is that we > > > > allowed #SMI to happen during the STI interrupt shadow, > > > > and we did nothing to both reset it on #SMI handler > > > > entry and restore it on RSM. > > > > > > I have now sent out the final/new version of the first 8 patches and > > > will review these tomorrow. Thanks for your patience. :) > > > > > > Paolo > > > > > Thank you very much!! > > Queued, thanks. Note that some emulator patches should go in stable > releases so I have reordered them in front. Can you fix patch 04 (also patch 04 in your series[*]) before pushing to kvm/queue? The unused variable breaks CONFIG_KVM_WERROR=y builds. arch/x86/kvm/smm.c: In function ‘emulator_leave_smm’: arch/x86/kvm/smm.c:567:33: error: unused variable ‘efer’ [-Werror=unused-variable] 567 | unsigned long cr0, cr4, efer; | ^~~~ arch/x86/kvm/smm.c:567:28: error: unused variable ‘cr4’ [-Werror=unused-variable] 567 | unsigned long cr0, cr4, efer; | [*] https://lore.kernel.org/all/Y1xNso2nYZkSSZ0T@google.com