lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251121204803.991707-3-yosry.ahmed@linux.dev>
Date: Fri, 21 Nov 2025 20:48:01 +0000
From: Yosry Ahmed <yosry.ahmed@...ux.dev>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: Sean Christopherson <seanjc@...gle.com>,
	Jim Mattson <jmattson@...gle.com>,
	kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Yosry Ahmed <yosry.ahmed@...ux.dev>
Subject: [PATCH v3 2/4] KVM: SVM: Don't set GIF when clearing EFER.SVME

From: Jim Mattson <jmattson@...gle.com>

Clearing EFER.SVME is not architected to set GIF. Don't set GIF when
emulating a change to EFER that clears EFER.SVME.

However, keep setting GIF if clearing EFER.SVME causes force-leaving the
nested guest through svm_leave_nested(), to maintain a sane behavior of
not leaving GIF cleared after exiting the guest.  In every other path,
setting GIF is either correct/desirable, or irrelevant because the
caller immediately and unconditionally sets/clears GIF.

This is more-or-less KVM defining HW behavior, but leaving GIF cleared
would also be defining HW behavior anyway.

Note that if force-leaving the nested guest is considered a SHUTDOWN,
then this could violate the APM-specified behavior:

  If the processor enters the shutdown state (due to a triple fault for
  instance) while GIF is clear, it can only be restarted by means of a
  RESET.

However, a SHUTDOWN leaves the VMCB undefined, so there's not a lot that
KVM can do in this case. Also, if vGIF is enabled on SHUTDOWN, KVM has
no way of finding out of GIF was cleared.

The only way for KVM to handle this without making up HW behavior is to
completely terminate the VM, so settle for doing the relatively "sane"
thing of setting GIF when force-leaving nested.

Fixes: c513f484c558 ("KVM: nSVM: leave guest mode when clearing EFER.SVME")
Signed-off-by: Jim Mattson <jmattson@...gle.com>
Co-developed-by: Sean Christopherson <seanjc@...gle.com>
Signed-off-by: Sean Christopherson <seanjc@...gle.com>
[yosry.ahmed: stitched together jmattson's patch and seanjc's diff]
Signed-off-by: Yosry Ahmed <yosry.ahmed@...ux.dev>
---
 arch/x86/kvm/svm/nested.c | 2 ++
 arch/x86/kvm/svm/svm.c    | 1 -
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c
index 3e4bd8d69788..9f91272fb735 100644
--- a/arch/x86/kvm/svm/nested.c
+++ b/arch/x86/kvm/svm/nested.c
@@ -1363,6 +1363,8 @@ void svm_leave_nested(struct kvm_vcpu *vcpu)
 		nested_svm_uninit_mmu_context(vcpu);
 		vmcb_mark_all_dirty(svm->vmcb);
 
+		svm_set_gif(svm, true);
+
 		if (kvm_apicv_activated(vcpu->kvm))
 			kvm_make_request(KVM_REQ_APICV_UPDATE, vcpu);
 	}
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index f56c2d895011..f62e94b404f4 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -215,7 +215,6 @@ int svm_set_efer(struct kvm_vcpu *vcpu, u64 efer)
 	if ((old_efer & EFER_SVME) != (efer & EFER_SVME)) {
 		if (!(efer & EFER_SVME)) {
 			svm_leave_nested(vcpu);
-			svm_set_gif(svm, true);
 			/* #GP intercept is still needed for vmware backdoor */
 			if (!enable_vmware_backdoor)
 				clr_exception_intercept(svm, GP_VECTOR);
-- 
2.52.0.rc2.455.g230fcf2819-goog


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ