From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>,
xen-devel <xen-devel@lists.xenproject.org>
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>
Subject: Re: [PATCH 3/3] x86/HVM: don't crash guest upon problems occurring in user mode
Date: Thu, 20 Nov 2014 11:06:28 +0000 [thread overview]
Message-ID: <546DCB34.8030302@citrix.com> (raw)
In-Reply-To: <546DCCC202000078000493F8@smtp.nue.novell.com>
[-- Attachment #1.1: Type: text/plain, Size: 4952 bytes --]
On 20/11/14 10:13, Jan Beulich wrote:
> This extends commit 5283b310 ("x86/HVM: only kill guest when unknown VM
> exit occurred in guest kernel mode") to further cases, including the
> failed VM entry one that XSA-110 was needed to be issued for.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -90,6 +90,15 @@ static bool_t amd_erratum383_found __rea
> static uint64_t osvw_length, osvw_status;
> static DEFINE_SPINLOCK(osvw_lock);
>
> +/* Only crash the guest if the problem originates in kernel mode. */
> +static void svm_crash_or_gp(struct vcpu *v)
> +{
> + if ( vmcb_get_cpl(v->arch.hvm_svm.vmcb) )
> + hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
This (and its VMX counterpart) should either deliver a #GP fault, or
have its name changed to not imply a #GP fault.
How about "crash_or_fault()" as an alternative which is slightly less
specific?
~Andrew
> + else
> + domain_crash(v->domain);
> +}
> +
> void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_len)
> {
> struct vcpu *curr = current;
> @@ -100,7 +109,7 @@ void __update_guest_eip(struct cpu_user_
> if ( unlikely(inst_len > 15) )
> {
> gdprintk(XENLOG_ERR, "Bad instruction length %u\n", inst_len);
> - domain_crash(curr->domain);
> + svm_crash_or_gp(curr);
> return;
> }
>
> @@ -1505,7 +1514,7 @@ static void svm_do_nested_pgfault(struct
> gdprintk(XENLOG_ERR,
> "SVM violation gpa %#"PRIpaddr", mfn %#lx, type %i\n",
> gpa, mfn_x(mfn), p2mt);
> - domain_crash(v->domain);
> + svm_crash_or_gp(v);
> }
>
> static void svm_fpu_dirty_intercept(void)
> @@ -2647,7 +2656,7 @@ void svm_vmexit_handler(struct cpu_user_
> printk(XENLOG_G_ERR
> "%pv: Error %d handling NPF (gpa=%08lx ec=%04lx)\n",
> v, rc, vmcb->exitinfo2, vmcb->exitinfo1);
> - domain_crash(v->domain);
> + svm_crash_or_gp(v);
> }
> v->arch.hvm_svm.cached_insn_len = 0;
> break;
> @@ -2680,11 +2689,7 @@ void svm_vmexit_handler(struct cpu_user_
> "exitinfo1 = %#"PRIx64", exitinfo2 = %#"PRIx64"\n",
> exit_reason,
> (u64)vmcb->exitinfo1, (u64)vmcb->exitinfo2);
> - if ( vmcb_get_cpl(vmcb) )
> - hvm_inject_hw_exception(TRAP_invalid_op,
> - HVM_DELIVER_NO_ERROR_CODE);
> - else
> - domain_crash(v->domain);
> + svm_crash_or_gp(v);
> break;
> }
>
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -134,6 +134,18 @@ static void vmx_vcpu_destroy(struct vcpu
> passive_domain_destroy(v);
> }
>
> +/* Only crash the guest if the problem originates in kernel mode. */
> +static void vmx_crash_or_gp(struct vcpu *v)
> +{
> + struct segment_register ss;
> +
> + vmx_get_segment_register(v, x86_seg_ss, &ss);
> + if ( ss.attr.fields.dpl )
> + hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE);
> + else
> + domain_crash(v->domain);
> +}
> +
> static DEFINE_PER_CPU(struct vmx_msr_state, host_msr_state);
>
> static const u32 msr_index[] =
> @@ -2474,7 +2486,7 @@ static void ept_handle_violation(unsigne
> if ( qualification & EPT_GLA_VALID )
> gdprintk(XENLOG_ERR, " --- GLA %#lx\n", gla);
>
> - domain_crash(d);
> + vmx_crash_or_gp(current);
> }
>
> static void vmx_failed_vmentry(unsigned int exit_reason,
> @@ -2508,7 +2520,7 @@ static void vmx_failed_vmentry(unsigned
> vmcs_dump_vcpu(curr);
> printk("**************************************\n");
>
> - domain_crash(curr->domain);
> + vmx_crash_or_gp(curr);
> }
>
> void vmx_enter_realmode(struct cpu_user_regs *regs)
> @@ -3161,19 +3173,8 @@ void vmx_vmexit_handler(struct cpu_user_
> /* fall through */
> default:
> exit_and_crash:
> - {
> - struct segment_register ss;
> -
> - gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n",
> - exit_reason);
> -
> - vmx_get_segment_register(v, x86_seg_ss, &ss);
> - if ( ss.attr.fields.dpl )
> - hvm_inject_hw_exception(TRAP_invalid_op,
> - HVM_DELIVER_NO_ERROR_CODE);
> - else
> - domain_crash(v->domain);
> - }
> + gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n", exit_reason);
> + vmx_crash_or_gp(v);
> break;
> }
>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
[-- Attachment #1.2: Type: text/html, Size: 5497 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2014-11-20 11:06 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-20 10:04 [PATCH 0/3] x86: XSA-109/110 follow-up (to be considered for 4.5) Jan Beulich
2014-11-20 10:11 ` [PATCH 1/3] x86: tighten page table owner checking in do_mmu_update() Jan Beulich
2014-11-20 10:29 ` Andrew Cooper
2014-11-20 10:33 ` Andrew Cooper
2014-11-20 10:12 ` [PATCH 2/3] x86: don't ignore foreigndom input on various MMUEXT ops Jan Beulich
2014-11-20 10:51 ` Tim Deegan
2014-11-24 12:43 ` George Dunlap
2014-11-24 12:50 ` Jan Beulich
2014-11-20 10:13 ` [PATCH 3/3] x86/HVM: don't crash guest upon problems occurring in user mode Jan Beulich
2014-11-20 11:06 ` Andrew Cooper [this message]
2014-11-20 11:14 ` Jan Beulich
2014-11-20 11:34 ` Tim Deegan
2014-11-20 13:11 ` Jan Beulich
2014-11-20 15:37 ` [PATCH v2 " Jan Beulich
2014-11-20 15:41 ` Tim Deegan
2014-11-20 15:42 ` Andrew Cooper
2014-11-24 11:49 ` [PATCH 0/3] x86: XSA-109/110 follow-up (to be considered for 4.5) Jan Beulich
2014-11-24 17:11 ` Konrad Rzeszutek Wilk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=546DCB34.8030302@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=keir@xen.org \
--cc=tim@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.