linux-kernel - Re: [PATCH 08/14] kvm: x86: don't kill guest on unknown exit reason

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: <544A9320.6010102@amacapital.net>
Date:	Fri, 24 Oct 2014 10:57:52 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Paolo Bonzini <pbonzini@...hat.com>, linux-kernel@...r.kernel.org,
	kvm@...r.kernel.org
CC:	"Michael S. Tsirkin" <mst@...hat.com>, stable@...r.kernel.org
Subject: Re: [PATCH 08/14] kvm: x86: don't kill guest on unknown exit reason

On 10/24/2014 08:07 AM, Paolo Bonzini wrote:
> From: "Michael S. Tsirkin" <mst@...hat.com>
> 
> KVM_EXIT_UNKNOWN is a kvm bug, we don't really know whether it was
> triggered by a priveledged application.  Let's not kill the guest: WARN
> and inject #UD instead.

This scares me a bit.  For guest CPL3, it's probably okay.  For guest
CPL0, on the other hand, #UD might not use IST (or a task switch on
32-bit guests), resulting in possible corruption if unprivileged code
controls SP.  Admittedly, there aren't that many contexts from which
that should happen (on Linux, at least), but something like #DF (or even
a triple fault) might be safer if the guest is at CPL0 when this happens.

--Andy

> 
> Cc: stable@...r.kernel.org
> Signed-off-by: Michael S. Tsirkin <mst@...hat.com>
> Signed-off-by: Paolo Bonzini <pbonzini@...hat.com>
> ---
>  arch/x86/kvm/svm.c | 6 +++---
>  arch/x86/kvm/vmx.c | 6 +++---
>  2 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index 00bed2c5e948..7527cefc5a43 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -3551,9 +3551,9 @@ static int handle_exit(struct kvm_vcpu *vcpu)
>  
>  	if (exit_code >= ARRAY_SIZE(svm_exit_handlers)
>  	    || !svm_exit_handlers[exit_code]) {
> -		kvm_run->exit_reason = KVM_EXIT_UNKNOWN;
> -		kvm_run->hw.hardware_exit_reason = exit_code;
> -		return 0;
> +		WARN_ONCE(1, "vmx: unexpected exit reason 0x%x\n", exit_code);
> +		kvm_queue_exception(vcpu, UD_VECTOR);
> +		return 1;
>  	}
>  
>  	return svm_exit_handlers[exit_code](svm);
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index cf3cd079ec52..a8b76c4c95e2 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -7174,10 +7174,10 @@ static int vmx_handle_exit(struct kvm_vcpu *vcpu)
>  	    && kvm_vmx_exit_handlers[exit_reason])
>  		return kvm_vmx_exit_handlers[exit_reason](vcpu);
>  	else {
> -		vcpu->run->exit_reason = KVM_EXIT_UNKNOWN;
> -		vcpu->run->hw.hardware_exit_reason = exit_reason;
> +		WARN_ONCE(1, "vmx: unexpected exit reason 0x%x\n", exit_reason);
> +		kvm_queue_exception(vcpu, UD_VECTOR);
> +		return 1;
>  	}
> -	return 0;
>  }
>  
>  static void update_cr8_intercept(struct kvm_vcpu *vcpu, int tpr, int irr)
> 

--
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/