Re: [Xen-devel] [PATCH v1 0/2] Extend ioreq-server to support page write protection

["Ye, Wei" <wei.ye@xxxxxxxxx>]

Some summary of the discussion:

Without vt-d page fault support, a general write-protection is not possible. 
It's impossible to protect the write of both CPU and DMA path.
But note that XenGT itself doesn't use VT-d, and there is no another usage of 
having another device DMA to GPU resource. Or even other
device use the protect page for its DMA buffer, like a malicious guest, there 
is no security hole since it can only access it's our memory range.
So, just keep protecting the CPU write path may be feasible for this moment.

Another way is treat the page as MMIO ranges(means removing mapping in both 
EPD/VT-D page table). In this way, both read/write access
should be forwarded and emulated. For XenGT usage case, we observed that for 
the Linux guest, there is no read access to the ppgtt page
tables. And for the windows guest, the read access is just about 20% of write. 
The read overhead is relatively small, so treat the pages as MMIO
range may be possible.

Any comments?

Regards
Wei

> -----Original Message-----
> From: Tian, Kevin
> Sent: Saturday, August 9, 2014 12:04 AM
> To: Jan Beulich
> Cc: ian.campbell@xxxxxxxxxx; Paul.Durrant@xxxxxxxxxx;
> ian.jackson@xxxxxxxxxxxxx; stefano.stabellini@xxxxxxxxxxxxx; Dugger, Donald
> D; Ye, Wei; Zhang, Yang Z; Lv, Zhiyuan; xen-devel@xxxxxxxxxxxxx; Konrad
> Rzeszutek Wilk; keir@xxxxxxx; tim@xxxxxxx
> Subject: RE: [Xen-devel] [PATCH v1 0/2] Extend ioreq-server to support page
> write protection
> 
> > From: Tian, Kevin
> > Sent: Friday, August 08, 2014 9:02 AM
> >
> > > From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> > > Sent: Thursday, August 07, 2014 11:33 PM
> > >
> > > >>> On 07.08.14 at 18:28, <kevin.tian@xxxxxxxxx> wrote:
> > > >>  From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> > > >> Sent: Wednesday, August 06, 2014 11:45 PM
> > > >> >>> On 06.08.14 at 18:08, <kevin.tian@xxxxxxxxx> wrote:
> > > >> > It would be a severe security hole to write-protect only the
> > > >> > CPU path
> > > while
> > > >> > leaving DMA writes valid. When we say a page is
> > > >> > write-protected, it
> > must
> > > be
> > > >> > consistently enforced in both CPU/DMA paths. Now there is no
> > > >> > other
> > way
> > > to
> > > >> > achieve it lacking of VT-d page fault, except treating it fully
> > > >> > as a
> > > emulated
> > > >> > MMIO range (means removing mapping in both EPT/VT-d page
> > > >> > table),
> > or
> > > >> > excluding VT-d like this patch originally does.
> > > >>
> > > >> A fully emulated range means more than just removing the mapping
> > > >> though: No passed through device must access the memory range,
> > > >> since you can't emulate such accesses. While this is fine for
> > > >> existing uses (LAPIC, HPET, ...), I don't think it is for things
> > > >> like a frame buffer. If otoh talk is exclusively about GPU page
> > > >> tables, then this
> > > >
> > > > I don't understand here. why would a pass-through device wants to
> > > > access frame buffer (I think you meant 'virtual' frame buffer)?
> > > > Note XenGT itself doesn't use VT-d, and we didn't see such usage
> > > > of having another device DMA to GPU resource. Then it's just same
> > > > as any existing emulated MMIO ranges e.g. on a virtual NIC, where
> > > > no pass-through device would access them.
> > >
> > > This is the same as the discussion about VT-d code not supporting
> > > large pages right now: An OS _might_ do clever things (merely
> > > dumping the frame buffer verbatim to disk or network would be one of
> > > the more trivial examples). Current OSes (or more precisely their
> > > drivers) may not do this, but I can only repeat my fundamental
> > > position here: We should not make assumptions about HVM guest
> > > behavior except in cases where we want to optimize certain things.
> >
> > with a complete HW support yes we should make assumption for guest
> 
> should -> shouldn't
> 
> > behavior (e.g. with VT-x we can support any type of OS), but when HW
> > support in VT-d is not fully ready, then making some assumption makes
> > sense especially when no real usage is observed in this case.
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel