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

[David Vrabel <david.vrabel@xxxxxxxxxx>]

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.

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.

David

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