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

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

> 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@xxxxxxxx]
> >>>> Sent: Tuesday, August 05, 2014 12:52 AM
> >>>>
> >>>>>>> On 05.08.14 at 09:35, <yang.z.zhang@xxxxxxxxx> wrote: Tian,
> >>>>>>> Kevin wrote on 2014-08-05: From: Jan Beulich
> >>>>>>> [mailto:JBeulich@xxxxxxxx]
> >>>>>>> Sent: Monday, August 04, 2014 12:35 AM
> >>>>>>>
> >>>>>>>>>> On 04.08.14 at 07:05, <wei.ye@xxxxxxxxx> wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Jan Beulich wrote on 2014-07-28:
> >>>>>>>>> devel@xxxxxxxxxxxxx; keir@xxxxxxx
> >>>>>>>>> Subject: Re: [PATCH v1 0/2] Extend ioreq-server to support
> >>>>>>>>> page write protection
> >>>>>>>>>
> >>>>>>>>>>>> On 28.07.14 at 19:55, <wei.ye@xxxxxxxxx> 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-virtualizat 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 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.
There is no 'right data' to be ensured in such case. :-)

Thanks
Kevin

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