From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=56268 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OUcok-00007q-FD for qemu-devel@nongnu.org; Fri, 02 Jul 2010 05:45:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OUcoi-0002kp-51 for qemu-devel@nongnu.org; Fri, 02 Jul 2010 05:45:54 -0400 Received: from mail.valinux.co.jp ([210.128.90.3]:54985) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUcoh-0002kZ-M5 for qemu-devel@nongnu.org; Fri, 02 Jul 2010 05:45:52 -0400 Date: Fri, 2 Jul 2010 18:41:55 +0900 From: Isaku Yamahata Subject: Re: [Qemu-devel] Re: Status update Message-ID: <20100702094155.GC16712@valinux.co.jp> References: <20100629172522.GA8227@localhost> <20100701193034.GA7421@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: kvm@vger.kernel.org, joro@8bytes.org, qemu-devel@nongnu.org, paul@codesourcery.com, Eduard - Gabriel Munteanu , avi@redhat.com On Fri, Jul 02, 2010 at 09:03:39AM +0100, Stefan Hajnoczi wrote: > On Thu, Jul 1, 2010 at 8:30 PM, Eduard - Gabriel Munteanu > wrote: > > On Wed, Jun 30, 2010 at 09:37:31AM +0100, Stefan Hajnoczi wrote: > >> On Tue, Jun 29, 2010 at 6:25 PM, Eduard - Gabriel Munteanu > >> wrote: > >> > On the other hand, we could just leave it alone for now. Changing > >> > mappings during DMA is stupid anyway: I don't think the guest can > >> > recover the results of DMA safely, even though it might be used on > >> > transfers in progress you simply don't care about anymore. Paul Brook > >> > suggested we could update the cpu_physical_memory_map() mappings > >> > somehow, but I think that's kinda difficult to accomplish. > >> > >> A malicious or broken guest shouldn't be able to crash or corrupt QEMU > >> process memory. ?The IOMMU can only map from bus addresses to guest > >> physical RAM (?) so the worst the guest can do here is corrupt itself? > >> > > That's true, but it's fair to be concerned about the guest itself. > > Imagine it runs some possibly malicious apps which program the hardware > > to do DMA. That should be safe when a IOMMU is present. > > > > But suddenly the guest OS changes mappings and expects the IOMMU to > > enforce them as soon as invalidation commands are completed. The guest > > then reclaims the old space for other uses. This leaves an opportunity > > for those processes to corrupt or read sensitive data. In such a case, OS should put device into quiescence by reset like pci bus reset or pcie function level reset. pci bus reset patch hasn't been merged yet, though. It needs clean up/generalization. > > As long as QEMU acts in the same way as real hardware we should be > okay. Will real hardware change the mappings immediately and abort > the DMA from the device if it tries to access an invalidated address? > > Stefan > -- yamahata