Re: [Xen-devel] [PATCH 08/12] xen/grant-table: add a mechanism to safely unmap pages that are in use

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2015-01-07 at 13:07 +0000, David Vrabel wrote:
> On 07/01/15 12:00, Ian Campbell wrote:
> > On Tue, 2015-01-06 at 18:57 +0000, David Vrabel wrote:
> >> From: Jenny Herbert <jennifer.herbert@xxxxxxxxxx>
> >>
> >> Introduce gnttab_unmap_refs_async() that can be used to safely unmap
> >> pages that may be in use (ref count > 1).  If the pages are in use the
> >> unmap is deferred and retried later.  This polling is not very clever
> >> but it should be good enough if the cases where the delay is necessary
> >> are rare.
> >>
> >> This is needed to allow block backends using grant mapping to safely
> >> use network storage (block or filesystem based such as iSCSI or NFS).
> >>
> >> The network storage driver may complete a block request whilst there
> >> is a queued network packet retry (because the ack from the remote end
> >> races with deciding to queue the retry).  The pages for the retried
> >> packet would be grant unmapped and the network driver (or hardware)
> >> would access the unmapped page.
> > 
> > I thought this had been solved a little while ago by mapping a scratch
> > page on unmap even for kernel space grant mappings, but both the design
> > doc and here imply not (i.e. the scratch is for user grant mappings
> > only), so I must be misremembering.
> 
> It was only for user grant mappings and it did not fix the case where
> the page being unmapped was currently dma mapped.  This could have
> resulted in the NIC transmitting sensitive data.
> 
> e.g.,
> 
> 1. iscsi queues a retransmit with page P (frame F).
> 2. NIC driver DMA maps and queues frame F on h/w.
> 3. iscsi completes the I/O.
> 4. page P is unmapped.
> 5. response is sent to guest
> 6. guest reuses frame F.
> 7. NIC transmits frame F.

You don't actually need Xen to expose this sort of thing, any userspace
which reuses a buffer after write() (to e.g. NFS has completed) might
expose the new data on the wire in a retransmit.

It's certainly much easier to expose with Xen, I'll grant (no pun
intended) you that.

> We don't use this safe unmap mechanism for netback because the zero copy
> stuff means we don't need it and the polling on the unmap is high
> latency and only good enough if the polling is needed very rarely.

I'd think it should be rare for netback too unless your network is made
of wet string.

Ian.


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