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

["Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>]

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.

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

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

> 
> Thanks
> Kevin


Best regards,
Yang



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