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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 26/11/14 16:53, Jan Beulich wrote:
>>>> 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
>

My v1 patch only fixes the VMX side of things.  SVM doesn't explicitly
identify a failed vmentry and lets it fall into the default case of the
vmexit handler.  As such, with v1, the infinite loop still affects AMD
hardware.

~Andrew

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