From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell 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:24:51 +0000 Message-ID: <1420637091.18631.84.camel@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> <54AD2F93.209@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y8qcN-00071A-73 for xen-devel@lists.xenproject.org; Wed, 07 Jan 2015 13:25:47 +0000 In-Reply-To: <54AD2F93.209@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: David Vrabel Cc: xen-devel@lists.xenproject.org, Boris Ostrovsky , Jenny Herbert , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org 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 > >> > >> 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.