> -----Original Message----- > From: Julien Grall <jul...@xen.org> > Sent: 05 October 2020 15:42 > To: Paul Durrant <p...@xen.org>; xen-devel@lists.xenproject.org > Cc: Durrant, Paul <pdurr...@amazon.co.uk>; Jan Beulich <jbeul...@suse.com>; > Andrew Cooper > <andrew.coop...@citrix.com>; Roger Pau Monné <roger....@citrix.com>; Wei Liu > <w...@xen.org> > Subject: RE: [EXTERNAL] [PATCH] ioreq: cope with server disappearing while > I/O is pending > > CAUTION: This email originated from outside of the organization. Do not click > links or open > attachments unless you can confirm the sender and know the content is safe. > > > > Hi Paul, > > On 05/10/2020 15:08, Paul Durrant wrote: > > From: Paul Durrant <pdurr...@amazon.com> > > > > Currently, in the event of an ioreq server being destroyed while I/O is > > pending in the attached emulator, it is possible that hvm_wait_for_io() will > > dereference a pointer to a 'struct hvm_ioreq_vcpu' or the ioreq server's > > shared page after it has been freed. > > So the IOREQ code will call domain_pause() before destroying the IOREQ. > > A vCPU can only be descheduled in hvm_wait_for_io() from > wait_on_xen_event_channel(). AFAIK, we would schedule a new vCPU (or > idle) when this happens. > > On x86, the schedule() function will not return after context switch. > Therefore... > > > This will only occur if the emulator (which is necessarily running in a > > service domain with some degree of privilege) does not complete pending I/O > > during tear-down and is not directly exploitable by a guest domain. > > ... I am not sure how this can happen on x86. Do you mind providing an > example?
Maybe I'm missing something, but I can't see anything that would prevent wait_from_xen_event_channel() returning after the ioreq server has been destroyed? The domain is only paused whilst destruction is in progress but both 'sv' and 'p' will be on-stack and thus, as soon as the domain is unpaused again, could be subject to UAF. Paul > > Note that on Arm, the schedule() function will return after context > switch. So the problem you describe is there from an arch-agnostic PoV. > > Cheers, > > -- > Julien Grall