RE: [PATCH] ioreq: cope with server disappearing while I/O is pending

["Durrant, Paul" <pdurrant@xxxxxxxxxxxx>]

> -----Original Message-----
> From: Julien Grall <julien@xxxxxxx>
> Sent: 05 October 2020 15:42
> To: Paul Durrant <paul@xxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx
> Cc: Durrant, Paul <pdurrant@xxxxxxxxxxxx>; Jan Beulich <jbeulich@xxxxxxxx>; 
> Andrew Cooper
> <andrew.cooper3@xxxxxxxxxx>; Roger Pau Monné <roger.pau@xxxxxxxxxx>; Wei Liu 
> <wl@xxxxxxx>
> 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 <pdurrant@xxxxxxxxxx>
> >
> > 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