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

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

> From: Tim Deegan [mailto:tim@xxxxxxx]
> Sent: Wednesday, August 13, 2014 1:39 AM
> 
> 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?

If there is, then it has to be in the unsupported feature list. I think it's 
fair 
enough since we all know w/o complete VT-d page fault support there's 
no solution for such usage. Pretty much like old days big real mode tricks
before hardware support is ready.

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

sorry original statement is inaccurate. there is no cross-VM security hole
since EPT/VT-d are fully under VMM's control, but yes out-of-VM security
tool might be broken... 

> 
> >  So, just keep protecting the CPU write path may be feasible for this
> moment.
> 
> I don't think so.

Could we introduce a cpu-write-protection attribute only for functional
usages which don't care about DMA path like in XenGT? Then out-of-VM
security tool relying on complete write-protection in both CPU/DMA
paths still need to wait full VT-d page fault. I know it's not clean, but
want to hear your comments anything we can do here in current stage. :-)

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

Aren't we talking about a similar option? ours is more conservative, not only
removing from IOMMU table, but also removing from EPT so both r/w are
trapped which serves the read-only requirements with performance penalty.
along this way we didn't aim to provide a general write-protection mechanism,
but just to extend ioreq server to support scattered mmio ranges. If adding
a new p2m type is deemed dirty, we may go to this option since it can meet
XenGT's requirement, and doesn't force other usages to go same route.

Actually separate or shared EPT/VT-d tables doesn't mean anything here. 
Removing the page from IOMMU tables still breaks guest's attempt. You 
protected it from write, but didn't emulate the DMA so it's still broken.

Thanks
Kevin

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