linux-kernel - Re: [PATCH v2] KVM: nVMX: Fix the NMI IDT-vectoring handling

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]

Date:   Thu, 22 Sep 2016 11:58:48 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Wanpeng Li <kernellwp@...il.com>, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org
Cc:     Wanpeng Li <wanpeng.li@...mail.com>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Jan Kiszka <jan.kiszka@...mens.com>,
        Bandan Das <bsd@...hat.com>
Subject: Re: [PATCH v2] KVM: nVMX: Fix the NMI IDT-vectoring handling



On 22/09/2016 11:55, Wanpeng Li wrote:
> From: Wanpeng Li <wanpeng.li@...mail.com>
> 
> Run kvm-unit-tests/eventinj.flat in L1:
> 
> Sending NMI to self
> After NMI to self
> FAIL: NMI
> 
> This test scenario is to test whether VMM can handle NMI IDT-vectoring info correctly.
> 
> At the beginning, L2 writes LAPIC to send a self NMI, the EPT page tables on both L1 
> and L0 are empty so:
> 
> - The L2 accesses memory can generate EPT violation which can be intercepted by L0.
> 
>   The EPT violation vmexit occurred during delivery of this NMI, and the NMI info is 
>   recorded in vmcs02's IDT-vectoring info.
> 
> - L0 walks L1's EPT12 and L0 sees the mapping is invalid, it injects the EPT violation into L1.
> 
>   The vmcs02's IDT-vectoring info is reflected to vmcs12's IDT-vectoring info since 
>   it is a nested vmexit. 
>   
> - L1 receives the EPT violation, then fixes its EPT12.
> - L1 executes VMRESUME to resume L2 which generates vmexit and causes L1 exits to L0.
> - L0 emulates VMRESUME which is called from L1, then return to L2.
> 
>   L0 merges the requirement of vmcs12's IDT-vectoring info and injects it to L2 through 
>   vmcs02.
> 
> - The L2 re-executes the fault instruction and cause EPT violation again.
> - Since the L1's EPT12 is valid, L0 can fix its EPT02
> - L0 resume L2
> 	
>   The EPT violation vmexit occurred during delivery of this NMI again, and the NMI info 
>   is recorded in vmcs02's IDT-vectoring info. L0 should inject the NMI through vmentry 
>   event injection since it is caused by EPT02's EPT violation.
> 
> However, vmx_inject_nmi() refuses to inject NMI from IDT-vectoring info if vCPU is in 
> guest mode, this patch fix it by permitting to inject NMI from IDT-vectoring if it is 
> the L0's responsibility to inject NMI from IDT-vectoring info to L2.
> 
> Cc: Paolo Bonzini <pbonzini@...hat.com>
> Cc: Radim Krčmář <rkrcmar@...hat.com>
> Cc: Jan Kiszka <jan.kiszka@...mens.com>
> Cc: Bandan Das <bsd@...hat.com>
> Signed-off-by: Wanpeng Li <wanpeng.li@...mail.com>
> ---
> v1 -> v2: 
>  * move the if (vmx->rmode.vm86_active) part out if (!is_guest_mode())

Reviewed-by: Paolo Bonzini <pbonzini@...hat.com>

> 
>  arch/x86/kvm/vmx.c | 31 ++++++++++++++++---------------
>  1 file changed, 16 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 813658d..5429a43 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -5309,29 +5309,30 @@ static void vmx_inject_nmi(struct kvm_vcpu *vcpu)
>  {
>  	struct vcpu_vmx *vmx = to_vmx(vcpu);
>  
> -	if (is_guest_mode(vcpu))
> -		return;
> +	if (!is_guest_mode(vcpu)) {
> +		if (!cpu_has_virtual_nmis()) {
> +			/*
> +			 * Tracking the NMI-blocked state in software is built upon
> +			 * finding the next open IRQ window. This, in turn, depends on
> +			 * well-behaving guests: They have to keep IRQs disabled at
> +			 * least as long as the NMI handler runs. Otherwise we may
> +			 * cause NMI nesting, maybe breaking the guest. But as this is
> +			 * highly unlikely, we can live with the residual risk.
> +			 */
> +			vmx->soft_vnmi_blocked = 1;
> +			vmx->vnmi_blocked_time = 0;
> +		}
>  
> -	if (!cpu_has_virtual_nmis()) {
> -		/*
> -		 * Tracking the NMI-blocked state in software is built upon
> -		 * finding the next open IRQ window. This, in turn, depends on
> -		 * well-behaving guests: They have to keep IRQs disabled at
> -		 * least as long as the NMI handler runs. Otherwise we may
> -		 * cause NMI nesting, maybe breaking the guest. But as this is
> -		 * highly unlikely, we can live with the residual risk.
> -		 */
> -		vmx->soft_vnmi_blocked = 1;
> -		vmx->vnmi_blocked_time = 0;
> +		++vcpu->stat.nmi_injections;
> +		vmx->nmi_known_unmasked = false;
>  	}
>  
> -	++vcpu->stat.nmi_injections;
> -	vmx->nmi_known_unmasked = false;
>  	if (vmx->rmode.vm86_active) {
>  		if (kvm_inject_realmode_interrupt(vcpu, NMI_VECTOR, 0) != EMULATE_DONE)
>  			kvm_make_request(KVM_REQ_TRIPLE_FAULT, vcpu);
>  		return;
>  	}
> +
>  	vmcs_write32(VM_ENTRY_INTR_INFO_FIELD,
>  			INTR_TYPE_NMI_INTR | INTR_INFO_VALID_MASK | NMI_VECTOR);
>  }
>