From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH for-4.5 RFC v2] x86/HVM: Unconditionally crash guests on repeated vmentry failures Date: Wed, 26 Nov 2014 17:43:00 +0000 Message-ID: <54761124.60203@citrix.com> References: <1416934449-20299-1-git-send-email-andrew.cooper3@citrix.com> <5474C998020000780004AD1D@mail.emea.novell.com> <5474C658.4030901@citrix.com> <5476058A02000078000C2808@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5476058A02000078000C2808@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: tim@xen.org, keir@xen.org, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 26/11/14 16:53, Jan Beulich wrote: >>>> Andrew Cooper 11/25/14 7:14 PM >>> >> On 25/11/14 17:25, Jan Beulich wrote: >>>>>> On 25.11.14 at 17:54, 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