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

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Wed, Aug 06, 2014 at 03:04:31AM +0000, Zhang, Yang Z wrote:
> Tian, Kevin wrote on 2014-08-06:
> >> From: Tian, Kevin
> >> Sent: Tuesday, August 05, 2014 7:49 PM
> >> 
> >>> From: Zhang, Yang Z
> >>> Sent: Tuesday, August 05, 2014 7:40 PM
> >>> 
> >>> Tian, Kevin wrote on 2014-08-06:
> >>>>> From: Zhang, Yang Z
> >>>>> Sent: Tuesday, August 05, 2014 7:11 PM
> >>>>> 
> >>>>> Tian, Kevin wrote on 2014-08-05:
> >>>>>>> From: Jan Beulich [mailto:JBeulich@suse.com]
> >>>>>>> Sent: Tuesday, August 05, 2014 12:52 AM
> >>>>>>> 
> >>>>>>>>>> On 05.08.14 at 09:35, <yang.z.zhang@intel.com> wrote:
> >>>>>>>>>> Tian, Kevin wrote on 2014-08-05: From: Jan Beulich
> >>>>>>>>>> [mailto:JBeulich@suse.com]
> >>>>>>>>>> Sent: Monday, August 04, 2014 12:35 AM
> >>>>>>>>>> 
> >>>>>>>>>>>>> On 04.08.14 at 07:05, <wei.ye@intel.com> wrote:
> >>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>>> Jan Beulich wrote on 2014-07-28:
> >>>>>>>>>>>> devel@lists.xen.org; keir@xen.org
> >>>>>>>>>>>> Subject: Re: [PATCH v1 0/2] Extend ioreq-server to
> >>>>>>>>>>>> support page write protection
> >>>>>>>>>>>> 
> >>>>>>>>>>>>>>> On 28.07.14 at 19:55, <wei.ye@intel.com> wrote:
> >>>>>>>>>>>>> ioreq-server is proposed to forward PIO and MMIO request to
> >>>>>>>>>>>>> multiple device models according to the io range. XenGT
> >>>>>>>>>>>>> (Intel Graphics Virtualization technology, please refer to
> >>>>>>>>>>>>> https://01.org/xen/blogs/srclarkx/2013/graphics-virtual iz
> >>>>>>>>>>>>> at io n- xengt) driver reside in Dom0 as a virtual graphics
> >>>>>>>>>>>>> device model also need to trap and emulate the guest's write
> >>>>>>>>>>>>> operation to some specific memory pages, like the memory
> >>>>>>>>>>>>> pages used by guest graphics driver as PPGTT(per-process
> >>>>>>>>>>>>> graphics translation table). We add an new p2m type
> >>>>>>>>>>>>> "p2m_ram_wp" to trap the page write operation. Page of this
> >>>>>>>>>>>>> new p2m type is read only and for write, the request will go
> >>>>>>>>>>>>> to device model via
> > ioreq-server.
> >>>>>>>>>>>> 
> >>>>>>>>>>>> So how is this write-protection supposed to work on the
> >>>>>>>>>>>> IOMMU side when sharing page tables?
> >>>>>>>>>>> 
> >>>>>>>>>>> Thanks for pointing out this question. Write-protection is not
> >>>>>>>>>>> supposed to work when sharing page tables between EPT and
> >>>>>>>>>>> vt-d. An explicit command line "iommu=no-sharept" should be
> >>>>>>>>>>> setted for avoiding undesirable iommu fault.
> >>>>>>>>>> 
> >>>>>>>>>> Requiring the unconditional use of a specific command line
> >>>>>>>>>> option is certainly fine for experimental code, but not beyond that.
> >>>>>>>>>> Behavior should be correct by default in production code.
> >>>>>>>>>> 
> >>>>>>>>>> But what's worse here: The option _allows_ device side
> >>>>>>>>>> writes from the guest. Why would device side writes be
> >>>>>>>>>> okay, but CPU side ones not?
> >>>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> right, whether ept is shared or not doesn't address the concern
> >>>>>>>>> here. In both cases we need maintain the same p2m view between
> >>>>>>>>> CPU and device side, otherwise it's broken...
> >>>>>>>>> 
> >>>>>>>>> One option is to treat wp similar to logdirty, i.e.
> >>>>>>>>> exclusive to VT-d device assignment, until in the future
> >>>>>>>>> VT-d supports page fault. We can provide a boot option to
> >>>>>>>>> override the default policy if user thinks OK.
> >>>>>>>>> 
> >>>>>>>>> 2nd option, like Wei mentioned in another mail, is to treat
> >>>>>>>>> such write protected PPGTT page tables as MMIO. new
> >>>>>>>>> hypercall is required to change the p2m type between p2m_io
> >>>>>>>>> and p2m_ram, based on allocation/free of guest page table.
> >>>>>>>>> This way may impact performance on read though.
> >>>>>>>>> 
> >>>>>>>>> Comments?
> >>>>>>>> 
> >>>>>>>> Another solution is using the EPT misconfiguration mechanism
> >>>>>>>> like what Xen does for MTRR emulation currently.
> >>>>>>> 
> >>>>>>> That would cause faults on reads as well, making it necessary
> >>>>>>> to emulate them.
> >>>>>>> 
> >>>>>> 
> >>>>>> Then it's same effect of p2m_mmio_dm.
> >>>>> 
> >>>>> p2m_mmio_dm will break VT-d but EPT misconfiguration doesn't.
> >>>>> 
> >>>> 
> >>>> I don't understand. Treating it as emulated io just means no
> >>>> valid p2m entry in EPT/VT-d. Note XenGT itself doesn't require
> >>>> VT-d, while you can still assign other devices this way.
> >>> 
> >>> From guest's view, it doesn't know the page is not valid in EPT/VT-d
> >>> table. So if guest CPU touch this page, then hypervisor will intercept
> >>> the access from EPT violation and handle it. But if guest uses that
> >>> page as DMA buffer (a malicious guest may do it), then VT-d fault
> >>> happens. Since DMA is not restartable, guest will never receive the
> >>> right data.
> >>> 
> >> 
> >> as you said, it's malicious guest, that's why we need zap the VT-d
> 
> 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.

> 
> >> entries to avoid mallicous DMA to GPU page tables. In sane case the
> >> page is allocated by gfx driver so other device drivers with VT-d
> >> assigned devices shouldn't use it as DMA target.
> 
> What about a guest really does it?

Oh, here you say it can do it. A bit confusing.
> 
> >> There is no 'right data' to be ensured in such case. :-)
> >> 
> > 
> > Think about a malicious guest may DMA to any holes...
> 
> Other hole is not a RAM, so a VT-d fault is acceptable.

I feel that we talking about the same issue that had been raised before
about EPT and VT-d sharing a page and having issues with DMAing
in RAM regions (like into the framebuffer).

And my understanding is that Intel is going to fix it, except that
it is on the 'low-priority'. It sounds to me that it should be
raised to a higher priority and be taken care of.

> 
> > 
> > Thanks
> > Kevin
> 
> 
> Best regards,
> Yang
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel