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

[Tim Deegan <tim@xxxxxxx>]

At 23:15 +0000 on 12 Aug (1407881757), Ye, Wei wrote:
> Some summary of the discussion:
> 
> Without vt-d page fault support, a general write-protection is not
> possible. It's impossible to protect the write of both CPU and DMA
> path.  But note that XenGT itself doesn't use VT-d, and there is no
> another usage of having another device DMA to GPU resource.

None that you're aware of.  But there might be some out-of-tree users?

> Or even
> other device use the protect page for its DMA buffer, like a
> malicious guest, there is no security hole since it can only access
> it's our memory range.

Not true at all!  If the guest has a read-only mapping it must be
read-only for a reason.  For example, it might have a read-only grant
mapping of another VM's memory.  Or an out-of-VM security tool might
be enforcing W^X permissions.

>  So, just keep protecting the CPU write path may be feasible for this moment.

I don't think so. 

> Another way is treat the page as MMIO ranges(means removing mapping
> in both EPD/VT-D page table). In this way, both read/write access
> should be forwarded and emulated. For XenGT usage case, we observed
> that for the Linux guest, there is no read access to the ppgtt page
> tables. And for the windows guest, the read access is just about 20%
> of write. The read overhead is relatively small, so treat the pages
> as MMIO range may be possible.

That might work for XenGT but it doesn't address the general problem
at all.  AFAICT the only _safe_ way to make a page read-only to a guest
that can issue DMA is to remove it from the IOMMU tables - and that
means having separate EPT and vtD tables, until hardware support
for restartable IOMMU faults comes along.

Cheers,

Tim.

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