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: Wednesday, August 06, 2014 11:45 PM
> 
> >>> On 06.08.14 at 18:08, <kevin.tian@xxxxxxxxx> wrote:
> >>  From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@xxxxxxxxxx]
> >> On Wed, Aug 06, 2014 at 03:04:31AM +0000, Zhang, Yang Z wrote:
> >> > Malicious guest is just an example. We can assume a normal guest never
> >> does it.
> >>
> >> What!? No you can't. That is thundering towards an XSA! The normal
> >> guest can become compromised.
> >
> > 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.

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

Thanks
Kevin

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