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

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

> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@xxxxxxxxxx]
> Sent: Wednesday, August 06, 2014 8:01 AM
> 
> 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@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-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.

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.

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

I'm not in original discussion loop, but my feeling is w/o VT-d fault
support anything related to write-protection (e.g. logdirty) will remains
a gap here (i.e. the feature has to be exclusive to VT-d usage)

Thanks
Kevin

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