From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NllGe-0007oY-A5 for qemu-devel@nongnu.org; Sun, 28 Feb 2010 10:41:16 -0500 Received: from [199.232.76.173] (port=41255 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NllGc-0007oQ-T4 for qemu-devel@nongnu.org; Sun, 28 Feb 2010 10:41:14 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NllGb-0004L8-V7 for qemu-devel@nongnu.org; Sun, 28 Feb 2010 10:41:14 -0500 Received: from mx1.redhat.com ([209.132.183.28]:25219) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NllGb-0004L0-J3 for qemu-devel@nongnu.org; Sun, 28 Feb 2010 10:41:13 -0500 Date: Sun, 28 Feb 2010 17:37:50 +0200 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] Re: [PATCHv2 09/12] vhost: vhost net support Message-ID: <20100228153749.GD28921@redhat.com> References: <201002281245.07802.paul@codesourcery.com> <20100228144412.GC28921@redhat.com> <201002281523.06717.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201002281523.06717.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: amit.shah@redhat.com, quintela@redhat.com, qemu-devel@nongnu.org, kraxel@redhat.com On Sun, Feb 28, 2010 at 03:23:06PM +0000, Paul Brook wrote: > > So guest can cause vhost to write to a wrong place in RAM, but it can > > just pass a wrong address directly. > > That's not the point. Obviously any DMA capable device can be used to > compromise a system. However if a device writes to address B after being told > to write to address A, then you have a completely broken system. Yes, but I do not see how this can happen with vhost backed to virtio. > > As long as vhost does not access a > > non-RAM address, we are definitely fine. > > Why does it matter what it's changed to? The virtio DMA addresses guest > physical addresses. If guest physical address mappings change then the virtio > device must respect those changes. The extreme case is a system with an IOMMU > (not currently implemented in QEMU). In that case it's likely that physical- > RAM mappings will change frequently. > > Paul Yes, but this is already supported. The one thing that my patches assume does not change while device is active, is physical to qemu virtual mapping for virtio ring. Since virtio device is allowed to access the ring at any time, such changes would only legal when device is not active IMO, and my code translates physical to virtual when device is made active. So I do not see a bug. -- MST