linux-kernel - [PATCH v2] KVM: nVMX: Fix losing NMI blocking state

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-next>] [day] [month] [year] [list]

Date:   Tue, 25 Jul 2017 03:40:46 -0700
From:   Wanpeng Li <kernellwp@...il.com>
To:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Wanpeng Li <wanpeng.li@...mail.com>
Subject: [PATCH v2] KVM: nVMX: Fix losing NMI blocking state

Run kvm-unit-tests/eventinj.flat in L1 w/ ept=0 on both L0 and L1:

Before NMI IRET test
Sending NMI to self
NMI isr running stack 0x461000
Sending nested NMI to self
After nested NMI to self
Nested NMI isr running rip=40038e
After iret
After NMI to self
FAIL: NMI

Reference SDM 31.7.1.2:

 If the “virtual NMIs” VM-execution control is 1, bit 12 of the VM-exit
 interruption-information field indicates that the VM exit was due to a fault
 encountered during an execution of the IRET instruction that removed virtual-NMI
 blocking. In particular, it provides this indication if the following are both
 true:

  - Bit 31 (valid) in the IDT-vectoring information field is 0.
  - The value of bits 7:0 (vector) of the VM-exit interruption-information
    field is not 8 (the VM exit is not due to a double-fault exception).

 If both are true and bit 12 of the VM-exit interruption-information field is 1,
 there was virtual-NMI blocking before guest software executed the IRET instruction
 that caused the fault that caused the VM exit. The VMM should set bit 3 (blocking
 by NMI) in the interruptibility-state field (using VMREAD and VMWRITE) before
 resuming guest software.

Commit 4c4a6f790ee862 (KVM: nVMX: track NMI blocking state separately for each VMCS)
tracks NMI blocking state separately for vmcs01 and vmcs02. However it is not enough:

 - The L2 (kvm-unit-tests/eventinj.flat) generates NMI that will fault on IRET, so the 
   L2 can generate #PF which can be intercepted by L0. 
 - L0 walks L1's guest page table and sees the mapping is invalid, it resumes the L1 
   guest and injects the #PF into L1.
 - L1 awares it should set bit 3 (blocking by NMI) in the interruptibility-state field 
   and fix the shadow page table before resuming L2 guest.
 - L1 executes VMRESUME to resume L2 which generates vmexit and causes L1 exit to L0 
 - L0 emulates VMRESUME which is called from L1, however, it lost the interruptibility 
   state field which is updated in vmcs12 when prepare vmcs02
 - .........

This patch fixes it by updating nmi_known_unmasked when preparing vmcs02 from vmcs12.

Cc: Paolo Bonzini <pbonzini@...hat.com>
Cc: Radim Krčmář <rkrcmar@...hat.com>
Signed-off-by: Wanpeng Li <wanpeng.li@...mail.com>
---
 arch/x86/kvm/vmx.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 29fd8af..bc999a1 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -10041,6 +10041,8 @@ static int prepare_vmcs02(struct kvm_vcpu *vcpu, struct vmcs12 *vmcs12,
 			     vmcs12->vm_entry_instruction_len);
 		vmcs_write32(GUEST_INTERRUPTIBILITY_INFO,
 			     vmcs12->guest_interruptibility_info);
+		vmx->loaded_vmcs->nmi_known_unmasked =
+			!(vmcs12->guest_interruptibility_info & GUEST_INTR_STATE_NMI);
 	} else {
 		vmcs_write32(VM_ENTRY_INTR_INFO_FIELD, 0);
 	}
-- 
2.7.4