From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54623) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c9V3L-0005lc-TY for qemu-devel@nongnu.org; Wed, 23 Nov 2016 05:45:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c9V3C-0003RG-Eo for qemu-devel@nongnu.org; Wed, 23 Nov 2016 05:45:18 -0500 Received: from smtp.eu.citrix.com ([185.25.65.24]:10990) by eggs.gnu.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1c9V3C-0003QX-4l for qemu-devel@nongnu.org; Wed, 23 Nov 2016 05:45:14 -0500 From: Paul Durrant Date: Wed, 23 Nov 2016 10:45:11 +0000 Message-ID: <32f40702983e45cfabc3d40dc4a3522b@AMSPEX02CL03.citrite.net> References: <58356D610200007800121289@prv-mh.provo.novell.com> <58356E480200007800121296@prv-mh.provo.novell.com> <27145c26bfa849779baa52deddd09294@AMSPEX02CL03.citrite.net> <58357F200200007800121344@prv-mh.provo.novell.com> In-Reply-To: <58357F200200007800121344@prv-mh.provo.novell.com> Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 1/3] xen: fix quad word bufioreq handling List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Beulich Cc: Anthony Perard , Stefano Stabellini , xen-devel , "qemu-devel@nongnu.org" > -----Original Message----- > From: Jan Beulich [mailto:JBeulich@suse.com] > Sent: 23 November 2016 10:36 > To: Paul Durrant > Cc: Anthony Perard ; Stefano Stabellini > ; xen-devel ; > qemu-devel@nongnu.org > Subject: RE: [PATCH 1/3] xen: fix quad word bufioreq handling >=20 > >>> On 23.11.16 at 10:48, wrote: > >> From: Jan Beulich [mailto:JBeulich@suse.com] > >> Sent: 23 November 2016 09:24 > >> > >> We should not consume the second slot if it didn't get written yet. > >> Normal writers - i.e. Xen - would not update write_pointer between the > >> two writes, but the page may get fiddled with by the guest itself, and > >> we're better off entering an infinite loop in that case. > >> > > > > Xen would never put QEMU in this situation and the guest can't actually > > modify the page whilst it's in use, since activation of the IOREQ serve= r > > removes the page from the guest's p2m so the premise of the patch is no= t > > correct. >=20 > Is that the case even for pre-ioreq-server Xen versions? The issue > here was reported together with what became XSA-197, and it's > not been assigned its own XSA just because there are other ways > for a guest to place high load on its qemu process (and there are > ways to deal with such high load situations). >=20 No, if QEMU is using a default ioreq server (i.e. the legacy way of doing t= hings) then it's vulnerable to the guest messing with the rings and I'd for= gotten that migrated-in guests from old QEMUs also end up using the default= server, so I guess this is a worthy checkt to make... although maybe it's = best to just bail if the check fails, since it would indicate a malicious g= uest. Paul > Jan