Re: [Qemu-devel] [PATCH 1/3] xen: fix quad word bufioreq handling

[Paul Durrant]

> -----Original Message-----
> From: Jan Beulich [mailto:address@hidden
> Sent: 23 November 2016 10:36
> To: Paul Durrant <address@hidden>
> Cc: Anthony Perard <address@hidden>; Stefano Stabellini
> <address@hidden>; xen-devel <address@hidden>;
> address@hidden
> Subject: RE: [PATCH 1/3] xen: fix quad word bufioreq handling
> 
> >>> On 23.11.16 at 10:48, <address@hidden> wrote:
> >> From: Jan Beulich [mailto:address@hidden
> >> 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 server
> > removes the page from the guest's p2m so the premise of the patch is not
> > correct.
> 
> 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).
> 

No, if QEMU is using a default ioreq server (i.e. the legacy way of doing 
things) then it's vulnerable to the guest messing with the rings and I'd 
forgotten 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 guest.

  Paul

> Jan