Skip to content

Commit 3280cc2

Browse files
sean-jcbonzini
authored andcommitted
KVM: SVM: Don't apply SEV+SMAP workaround on code fetch or PT access
Resume the guest instead of synthesizing a triple fault shutdown if the instruction bytes buffer is empty due to the #NPF being on the code fetch itself or on a page table access. The SMAP errata applies if and only if the code fetch was successful and ucode's subsequent data read from the code page encountered a SMAP violation. In practice, the guest is likely hosed either way, but crashing the guest on a code fetch to emulated MMIO is technically wrong according to the behavior described in the APM. Signed-off-by: Sean Christopherson <[email protected]> Reviewed-by: Liam Merwick <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
1 parent 04c40f3 commit 3280cc2

File tree

1 file changed

+34
-9
lines changed

1 file changed

+34
-9
lines changed

arch/x86/kvm/svm/svm.c

Lines changed: 34 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -4263,6 +4263,7 @@ static bool svm_can_emulate_instruction(struct kvm_vcpu *vcpu, int emul_type,
42634263
{
42644264
bool smep, smap, is_user;
42654265
unsigned long cr4;
4266+
u64 error_code;
42664267

42674268
/* Emulation is always possible when KVM has access to all guest state. */
42684269
if (!sev_guest(vcpu->kvm))
@@ -4328,22 +4329,31 @@ static bool svm_can_emulate_instruction(struct kvm_vcpu *vcpu, int emul_type,
43284329
* loap uop with CPL=0 privileges. If the load hits a SMAP #PF, ucode
43294330
* gives up and does not fill the instruction bytes buffer.
43304331
*
4331-
* Detection:
4332-
* KVM reaches this point if the VM is an SEV guest, the CPU supports
4333-
* DecodeAssist, a #NPF was raised, KVM's page fault handler triggered
4334-
* emulation (e.g. for MMIO), and the CPU returned 0 in GuestIntrBytes
4335-
* field of the VMCB.
4332+
* As above, KVM reaches this point iff the VM is an SEV guest, the CPU
4333+
* supports DecodeAssist, a #NPF was raised, KVM's page fault handler
4334+
* triggered emulation (e.g. for MMIO), and the CPU returned 0 in the
4335+
* GuestIntrBytes field of the VMCB.
43364336
*
43374337
* This does _not_ mean that the erratum has been encountered, as the
43384338
* DecodeAssist will also fail if the load for CS:RIP hits a legitimate
43394339
* #PF, e.g. if the guest attempt to execute from emulated MMIO and
43404340
* encountered a reserved/not-present #PF.
43414341
*
4342-
* To reduce the likelihood of false positives, take action if and only
4343-
* if CR4.SMAP=1 (obviously required to hit the erratum) and CR4.SMEP=0
4344-
* or CPL=3. If SMEP=1 and CPL!=3, the erratum cannot have been hit as
4345-
* the guest would have encountered a SMEP violation #PF, not a #NPF.
4342+
* To hit the erratum, the following conditions must be true:
4343+
* 1. CR4.SMAP=1 (obviously).
4344+
* 2. CR4.SMEP=0 || CPL=3. If SMEP=1 and CPL<3, the erratum cannot
4345+
* have been hit as the guest would have encountered a SMEP
4346+
* violation #PF, not a #NPF.
4347+
* 3. The #NPF is not due to a code fetch, in which case failure to
4348+
* retrieve the instruction bytes is legitimate (see abvoe).
4349+
*
4350+
* In addition, don't apply the erratum workaround if the #NPF occurred
4351+
* while translating guest page tables (see below).
43464352
*/
4353+
error_code = to_svm(vcpu)->vmcb->control.exit_info_1;
4354+
if (error_code & (PFERR_GUEST_PAGE_MASK | PFERR_FETCH_MASK))
4355+
goto resume_guest;
4356+
43474357
cr4 = kvm_read_cr4(vcpu);
43484358
smep = cr4 & X86_CR4_SMEP;
43494359
smap = cr4 & X86_CR4_SMAP;
@@ -4353,6 +4363,21 @@ static bool svm_can_emulate_instruction(struct kvm_vcpu *vcpu, int emul_type,
43534363
kvm_make_request(KVM_REQ_TRIPLE_FAULT, vcpu);
43544364
}
43554365

4366+
resume_guest:
4367+
/*
4368+
* If the erratum was not hit, simply resume the guest and let it fault
4369+
* again. While awful, e.g. the vCPU may get stuck in an infinite loop
4370+
* if the fault is at CPL=0, it's the lesser of all evils. Exiting to
4371+
* userspace will kill the guest, and letting the emulator read garbage
4372+
* will yield random behavior and potentially corrupt the guest.
4373+
*
4374+
* Simply resuming the guest is technically not a violation of the SEV
4375+
* architecture. AMD's APM states that all code fetches and page table
4376+
* accesses for SEV guest are encrypted, regardless of the C-Bit. The
4377+
* APM also states that encrypted accesses to MMIO are "ignored", but
4378+
* doesn't explicitly define "ignored", i.e. doing nothing and letting
4379+
* the guest spin is technically "ignoring" the access.
4380+
*/
43564381
return false;
43574382
}
43584383

0 commit comments

Comments
 (0)