[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] backport of "x86/hvm: don't rely on shared ioreq state for completion handling" ?



>>> On 16.02.17 at 11:13, <Paul.Durrant@xxxxxxxxxx> wrote:
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: 16 February 2017 09:21
>> 
>> as it looks to be quite non-trivial an operation, did you happen to
>> have to backport commit 480b83162a to 4.4 or older, without
>> backporting all the ioreq server stuff at the same time? It looks to
>> me as if the issue predates the addition of ioreq servers, and us
>> having had customer reports here would seem to make this a
>> candidate fix (perhaps with at least 125833f5f1 ["x86: fix
>> ioreq-server event channel vulnerability"] also backported, which
>> also appears to address a pre-existing issue).
> 
> Sorry, no I don't have a back-port. Agreed that the issue existed prior to 
> ioreq servers but the checking was probably sufficiently lax that it never 
> resulted in a domain_crash(), just bad data coming back from an emulation 
> request.

Well, according to the reports we've got, maybe it was less likely
to trigger, but it looks like it wasn't lax enough. Albeit I'm yet to
get confirmation that the issue was only seen during domain
shutdown, which aiui was (leaving aside a guest fiddling with the
shared structure, in which case it deserves being crashed) the
only condition triggering that domain_crash().

Once I have aforementioned confirmation, would you mind if I
asked you to look over the backports, should I manage to create
them in the first place?

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.