From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCH 08/12] xen/grant-table: add a mechanism to safely unmap pages that are in use Date: Wed, 7 Jan 2015 13:07:31 +0000 Message-ID: <54AD2F93.209@citrix.com> References: <1420570657-8203-1-git-send-email-david.vrabel@citrix.com> <1420570657-8203-9-git-send-email-david.vrabel@citrix.com> <1420632022.18631.58.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y8qKm-0005xY-CL for xen-devel@lists.xenproject.org; Wed, 07 Jan 2015 13:07:36 +0000 In-Reply-To: <1420632022.18631.58.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , David Vrabel Cc: xen-devel@lists.xenproject.org, Boris Ostrovsky , Jenny Herbert , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On 07/01/15 12:00, Ian Campbell wrote: > On Tue, 2015-01-06 at 18:57 +0000, David Vrabel wrote: >> From: Jenny Herbert >> >> 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