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

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

> 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@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. :-)
> 

Think about a malicious guest may DMA to any holes...

Thanks
Kevin

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