From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=50917 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OUPU2-0004Q0-LV for qemu-devel@nongnu.org; Thu, 01 Jul 2010 15:31:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OUPTx-0000O8-F0 for qemu-devel@nongnu.org; Thu, 01 Jul 2010 15:31:38 -0400 Received: from mail-bw0-f45.google.com ([209.85.214.45]:56759) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OUPTx-0000Nm-AT for qemu-devel@nongnu.org; Thu, 01 Jul 2010 15:31:33 -0400 Received: by bwz5 with SMTP id 5so1271762bwz.4 for ; Thu, 01 Jul 2010 12:31:31 -0700 (PDT) Sender: Eduard - Gabriel Munteanu Date: Thu, 1 Jul 2010 22:30:34 +0300 From: Eduard - Gabriel Munteanu Message-ID: <20100701193034.GA7421@localhost> References: <20100629172522.GA8227@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: [Qemu-devel] Re: Status update List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: qemu-devel@nongnu.org, joro@8bytes.org, paul@codesourcery.com, kvm@vger.kernel.org, avi@redhat.com 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? > > Stefan 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. If the guest OS is prone to changing mappings during DMA, some process could continually set up, e.g., IDE DMA write transfers hoping to expose useful data it can't read otherwise. The buffer can be poisoned to see if someone went for the bait and wrote in that space. Actually I'm not that sure changing mappings during DMA is stupid, as the OS might want to reassign devices (where this is possible) to various processes. Reclaiming mappings seems normal when a processes dies during DMA, as the kernel has no way of telling whether DMA completed (or even started). Eduard