From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49202) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvPwP-0003Jd-IW for qemu-devel@nongnu.org; Mon, 01 Dec 2014 07:19:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XvPwJ-0006re-EK for qemu-devel@nongnu.org; Mon, 01 Dec 2014 07:18:57 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42911) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvPwJ-0006rW-0n for qemu-devel@nongnu.org; Mon, 01 Dec 2014 07:18:51 -0500 Date: Mon, 1 Dec 2014 14:18:43 +0200 From: "Michael S. Tsirkin" Message-ID: <20141201121843.GC17505@redhat.com> References: <1417105946-27374-1-git-send-email-mst@redhat.com> <20141127211304.GA26295@redhat.com> <20141128011646.GA27676@fam-t430.nay.redhat.com> <1417158306.3268.3@smtp.corp.redhat.com> <20141130164305.GA10852@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH RFC for-2.2] virtio-blk: force 1st s/g to match header List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Kevin Wolf , Marc =?iso-8859-1?Q?Mar=ED?= , Fam Zheng , Stefan Hajnoczi , Jason Wang , qemu-devel , Stefan Hajnoczi On Mon, Dec 01, 2014 at 12:07:07PM +0000, Peter Maydell wrote: > On 30 November 2014 at 16:43, Michael S. Tsirkin wrote: > > The result of this is host mapping leak. > > What effect does this have? Can this DOS host? > > I don't think we can DOS the host here. > > If Xen, we crash (but you can't use virtio-blk with Xen anyway) > Otherwise, if you managed to get address_space_map() to hand you > the bounce-buffer (by asking for dma to something other than RAM) > then we'll either hit an assertion or just end up never allowing > dma to/from non-RAM ever again for this guest. > The usual case would be that this was dma to/from ram, in > which case it's harmless if the virtio-backend never wrote to > the memory, and will fail to update dirty bitmaps for migration > etc if the backend did write. > > In any case I think that none of these outcomes are worse > than the "exit(1)" the current patch proposes. > > -- PMM Fair enough. Pls disregard the patch then, and we'll fix it properly for 2.3 when we set ANY_LAYOUT.