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: <jpgr3jehylb.fsf@linux.bootlegged.copy>
Date:	Wed, 25 Nov 2015 10:45:36 -0500
From:	Bandan Das <bsd@...hat.com>
To:	Haozhong Zhang <haozhong.zhang@...el.com>
Cc:	kvm@...r.kernel.org, Gleb Natapov <gleb@...nel.org>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] KVM: nVMX: remove incorrect vpid check in nested invvpid emulation

Haozhong Zhang <haozhong.zhang@...el.com> writes:

> This patch removes the vpid check when emulating nested invvpid
> instruction of type all-contexts invalidation. The existing code is
> incorrect because:
>  (1) According to Intel SDM Vol 3, Section "INVVPID - Invalidate
>      Translations Based on VPID", invvpid instruction does not check
>      vpid in the invvpid descriptor when its type is all-contexts
>      invalidation.

But iirc isn't vpid=0 reserved for root mode ? I think we don't want
L1 hypervisor to be able do a invvpid(0).

>  (2) According to the same document, invvpid of type all-contexts
>      invalidation does not require there is an active VMCS, so/and
>      get_vmcs12() in the existing code may result in a NULL-pointer
>      dereference. In practice, it can crash both KVM itself and L1
>      hypervisors that use invvpid (e.g. Xen).

If that is the case, then just check if it's null and return without
doing anything.

> Signed-off-by: Haozhong Zhang <haozhong.zhang@...el.com>
> ---
>  arch/x86/kvm/vmx.c | 5 -----
>  1 file changed, 5 deletions(-)
>
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 87acc52..af823a3 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -7394,11 +7394,6 @@ static int handle_invvpid(struct kvm_vcpu *vcpu)
>  
>  	switch (type) {
>  	case VMX_VPID_EXTENT_ALL_CONTEXT:
> -		if (get_vmcs12(vcpu)->virtual_processor_id == 0) {
> -			nested_vmx_failValid(vcpu,
> -				VMXERR_INVALID_OPERAND_TO_INVEPT_INVVPID);
> -			return 1;
> -		}
>  		__vmx_flush_tlb(vcpu, to_vmx(vcpu)->nested.vpid02);
>  		nested_vmx_succeed(vcpu);
>  		break;

I also noticed a BUG() here in the default. It might be a good idea to replace
it with a WARN.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ