[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |