[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" ?


  • To: 'Jan Beulich' <JBeulich@xxxxxxxx>
  • From: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
  • Date: Thu, 16 Feb 2017 10:13:53 +0000
  • Accept-language: en-GB, en-US
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 16 Feb 2017 10:14:13 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: AQHSiDX5DBYfK69W4E2di3tyZ+G19aFracKg
  • Thread-topic: backport of "x86/hvm: don't rely on shared ioreq state for completion handling" ?

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 16 February 2017 09:21
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
> Subject: backport of "x86/hvm: don't rely on shared ioreq state for
> completion handling" ?
> 
> Paul,
> 
> 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).
> 

Hi Jan,

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.

  Paul

> Thanks, 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®.