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

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

> 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
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. 

> 
> >> ought to be fine, but would - to me - not fit with other aspects
> >> discussed in the context of these patches (like the supposedly large
> >> number of pages needing to be tracked for a guest).
> >
> > So what's your suggestion here?
> 
> I can't answer that without you clarifying whether talk earlier on
> was about the frame buffer or page tables.
> 

In our case it's only GPU page table. XenGT assigns frame buffer to the
VM so there's no concern in that path.

Thanks
Kevin

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