Re: [Xen-devel] [PATCH for-4.5 RFC v2] x86/HVM: Unconditionally crash guests on repeated vmentry failures

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 25/11/14 17:25, Jan Beulich wrote:
>>>> On 25.11.14 at 17:54, <andrew.cooper3@xxxxxxxxxx> wrote:
>> This is RFC as there is still a niggle.  I tested this via a partial revert 
>> of
>> the XSA-110 fix but the result is quite chatty given a double VMCB dump and
>> domain crash.  However, I am not sure we want to make any vmentry failure
>> quite, as any vmentry failure constitues a Xen bug.
> I think that double printing would be tolerable, but I've had yet
> another idea: Couldn't we make the second exception a #DF,
> thus having the guest killed via triple fault in the worst case at
> the third recurring failure (via hvm_combine_hw_exceptions())?

That still won't catch a large class of vmentry failures from bad host
state.  There needs to be some cutoff where we simply give up and crash
the domain.  In the end, this is just an exercise in how much we attempt
to recover in the case that we have already hit a hypervisor bug, and
can't be completely certain about any state.

Furthermore, guest userspace being able to exploit a Xen bug to result
in a triple fault is no better than an instant domain_crash(), from a
VMs point of view.  However, from a toolstacks point of view, it is even
worse, as malicious userspace could tie up toolstack resource in
domain_kill() and domain_create() (as a triple fault is modelled as a
clean reboot).

>
> Also your test results point out that we're delivering such an
> exception with wrong context to the guest: Machine state should
> match that before the results from the emulation got committed.
> But doing so would be a pretty significant change for almost no
> benefit.

Agreed, on both counts.

~Andrew



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel