From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gk95p-0007I9-Co for qemu-devel@nongnu.org; Tue, 14 Nov 2006 19:57:33 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gk95o-0007FZ-H7 for qemu-devel@nongnu.org; Tue, 14 Nov 2006 19:57:32 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gk95o-0007FM-DS for qemu-devel@nongnu.org; Tue, 14 Nov 2006 19:57:32 -0500 Received: from [65.74.133.4] (helo=mail.codesourcery.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1Gk95p-00066Q-0B for qemu-devel@nongnu.org; Tue, 14 Nov 2006 19:57:33 -0500 From: Paul Brook Subject: Re: [Qemu-devel] Recursion in cpu_physical_memory_rw Date: Wed, 15 Nov 2006 00:57:24 +0000 References: <20061115004350.GA21745@gondor.apana.org.au> In-Reply-To: <20061115004350.GA21745@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611150057.27235.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Xen Development Mailing List , Herbert Xu On Wednesday 15 November 2006 00:43, Herbert Xu wrote: > Hi: > > A number of qemu driver backends (such as rtl8139) call the function > cpu_physical_memory_rw to read/write guest memory. The target guest > memory address is often supplied by the guest. This opens up the > possibility of a guest giving an address which happens to be an MMIO > address which can potentially lead to infinite recursion involving > cpu_physical_memory_rw. > > Since these driver backends really only need to access system memory, > we could simply provide a new access interface that does not allow > MMIO addresses. It isn't always system memory. Some DMA controllers deliberately write to device FIFOs. There are also several devices which map areas of onboard RAM. At minimum you need to make those to use RAM mappings rather than MMIO. If a device is recursively writing to itself I'd take this as sign that the guest OS is already pretty screwed. I'm not sure what happens in this situation on real hardware, but I wouldn't be surprised if it caused similar effects by flooding the bus. Paul From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Brook Subject: Re: Recursion in cpu_physical_memory_rw Date: Wed, 15 Nov 2006 00:57:24 +0000 Message-ID: <200611150057.27235.paul@codesourcery.com> References: <20061115004350.GA21745@gondor.apana.org.au> Reply-To: qemu-devel@nongnu.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20061115004350.GA21745@gondor.apana.org.au> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org To: qemu-devel@nongnu.org Cc: Xen Development Mailing List , Herbert Xu List-Id: xen-devel@lists.xenproject.org On Wednesday 15 November 2006 00:43, Herbert Xu wrote: > Hi: > > A number of qemu driver backends (such as rtl8139) call the function > cpu_physical_memory_rw to read/write guest memory. The target guest > memory address is often supplied by the guest. This opens up the > possibility of a guest giving an address which happens to be an MMIO > address which can potentially lead to infinite recursion involving > cpu_physical_memory_rw. > > Since these driver backends really only need to access system memory, > we could simply provide a new access interface that does not allow > MMIO addresses. It isn't always system memory. Some DMA controllers deliberately write to device FIFOs. There are also several devices which map areas of onboard RAM. At minimum you need to make those to use RAM mappings rather than MMIO. If a device is recursively writing to itself I'd take this as sign that the guest OS is already pretty screwed. I'm not sure what happens in this situation on real hardware, but I wouldn't be surprised if it caused similar effects by flooding the bus. Paul