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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> 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