linux-kernel - [PATCH 1/2] KVM: SVM: Don't inject #UD if KVM attempts emulation of SEV guest w/o insn

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: <20230810234919.145474-2-seanjc@google.com>
Date:   Thu, 10 Aug 2023 16:49:17 -0700
From:   Sean Christopherson <seanjc@...gle.com>
To:     Sean Christopherson <seanjc@...gle.com>,
        Paolo Bonzini <pbonzini@...hat.com>
Cc:     kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        Wu Zongyo <wuzongyo@...l.ustc.edu.cn>,
        Tom Lendacky <thomas.lendacky@....com>
Subject: [PATCH 1/2] KVM: SVM: Don't inject #UD if KVM attempts emulation of
 SEV guest w/o insn

Don't inject a #UD if KVM attempts to emulate an instruction for an SEV
guest without a prefilled buffer, and instead resume the guest and hope
that it can make forward progress.  When commit 04c40f344def ("KVM: SVM:
Inject #UD on attempted emulation for SEV guest w/o insn buffer") added
the completely arbitrary #UD behavior, there were no known scenarios where
a well-behaved guest would induce a VM-Exit that triggered emulation, i.e.
it was thought that injecting #UD would be helpful.

However, now that KVM (correctly) attempts to re-inject INT3/INTO, e.g. if
a #NPF is encountered when attempting to deliver the INT3/INTO, an SEV
guest can trigger emulation without a buffer, through no fault of its own.
Resuming the guest and retrying the INT3/INTO is architecturally wrong,
e.g. the vCPU will incorrectly re-hit code #DBs, but for SEV guests there
is literally no other option that has a chance of making forward progress.

Drop the #UD injection for all flavors of emulation, even though that
means that a *misbehaving* guest will effectively end up in an infinite
loop instead of getting a #UD.  There's no evidence that suggests that an
unexpected #UD is actually better than hanging the vCPU, e.g. a soft-hung
vCPU can still respond to IRQs and NMIs to generate a backtrace.

Reported-by: Wu Zongyo <wuzongyo@...l.ustc.edu.cn>
Closes: https://lore.kernel.org/all/8eb933fd-2cf3-d7a9-32fe-2a1d82eac42a@mail.ustc.edu.cn
Fixes: 6ef88d6e36c2 ("KVM: SVM: Re-inject INT3/INTO instead of retrying the instruction")
Cc: stable@...r.kernel.org
Cc: Tom Lendacky <thomas.lendacky@....com>
Signed-off-by: Sean Christopherson <seanjc@...gle.com>
---
 arch/x86/kvm/svm/svm.c | 26 ++++++++++++++++----------
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 212706d18c62..581958c9dd4d 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -4725,18 +4725,24 @@ static bool svm_can_emulate_instruction(struct kvm_vcpu *vcpu, int emul_type,
 	 * and cannot be decrypted by KVM, i.e. KVM would read cyphertext and
 	 * decode garbage.
 	 *
-	 * Inject #UD if KVM reached this point without an instruction buffer.
-	 * In practice, this path should never be hit by a well-behaved guest,
-	 * e.g. KVM doesn't intercept #UD or #GP for SEV guests, but this path
-	 * is still theoretically reachable, e.g. via unaccelerated fault-like
-	 * AVIC access, and needs to be handled by KVM to avoid putting the
-	 * guest into an infinite loop.   Injecting #UD is somewhat arbitrary,
-	 * but its the least awful option given lack of insight into the guest.
+	 * Resume the guest if KVM reached this point without an instruction
+	 * buffer.  This path should *almost* never be hit by a well-behaved
+	 * guest, e.g. KVM doesn't intercept #UD or #GP for SEV guests.  But if
+	 * a #NPF occurs while the guest is vectoring an INT3/INTO, then KVM
+	 * will attempt to re-inject the INT3/INTO and skip the instruction.
+	 * In that scenario, retrying the INT3/INTO and hoping the guest will
+	 * make forward progress is the only option that has a chance of
+	 * success (and in practice it will work the vast majority of the time).
+	 *
+	 * This path is also theoretically reachable if the guest is doing
+	 * something odd, e.g. if the guest is triggering unaccelerated fault-
+	 * like AVIC access.  Resuming the guest will put it into an infinite
+	 * loop of sorts, but there's no hope of forward progress and injecting
+	 * an exception will at best yield confusing behavior, not to mention
+	 * break the INT3/INTO+#NPF case above.
 	 */
-	if (unlikely(!insn)) {
-		kvm_queue_exception(vcpu, UD_VECTOR);
+	if (unlikely(!insn))
 		return false;
-	}
 
 	/*
 	 * Emulate for SEV guests if the insn buffer is not empty.  The buffer
-- 
2.41.0.694.ge786442a9b-goog