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

["Jan Beulich" <jbeulich@xxxxxxxx>]

>>> Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 11/25/14 7:14 PM >>>
>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).

Right - the more I think about it, the more I'm inclined to take your v1 
patch...

Jan


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