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

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

> From: Tian, Kevin
> Sent: Wednesday, August 06, 2014 9:09 AM
> 
> > 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.
> 

Two corrections:

- it's still a functional problem instead of security problem. with EPT/VT-d a
malicious VM anyway can only access its own memory.

- A general write-protection mechanism is not possible until VT-d page fault
is there. The options just talk about XenGT specific requirement, which only
cares about CPU modification to the GPU page table.

Thanks
Kevin

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