From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GkQ3E-0007Px-Hb for qemu-devel@nongnu.org; Wed, 15 Nov 2006 14:04:00 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GkQ3C-0007M4-CQ for qemu-devel@nongnu.org; Wed, 15 Nov 2006 14:03:59 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GkQ3B-0007LD-Tz for qemu-devel@nongnu.org; Wed, 15 Nov 2006 14:03:57 -0500 Received: from [32.97.182.146] (helo=e6.ny.us.ibm.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GkQ3B-0000lq-KM for qemu-devel@nongnu.org; Wed, 15 Nov 2006 14:03:58 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id kAFJ3uvJ009534 for ; Wed, 15 Nov 2006 14:03:56 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kAFJ3afJ251730 for ; Wed, 15 Nov 2006 14:03:36 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kAFJ3ZoA031067 for ; Wed, 15 Nov 2006 14:03:35 -0500 Message-ID: <455B6486.8080604@us.ibm.com> From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Recursion in cpu_physical_memory_rw References: <20061115004350.GA21745@gondor.apana.org.au> <200611150057.27235.paul@codesourcery.com> <20061115025839.GA22608@gondor.apana.org.au> In-Reply-To: <20061115025839.GA22608@gondor.apana.org.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Wed, 15 Nov 2006 19:04:01 -0000 To: Herbert Xu Cc: Xen Development Mailing List , qemu-devel@nongnu.org Herbert Xu wrote: > On Wed, Nov 15, 2006 at 12:57:24AM +0000, Paul Brook wrote: >> 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. > > I'm not suggesting that we change all existing users of cpu_physical_* > to a new interface that only accessed RAM. However, for cases where it > is obvious that only system RAM is intended (e.g., rtl8139), it makes > sense to bypass MMIO handlers. > >> 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. > > The scenario here is a compromised guest attempting to harm a host such > as Xen. The only "harm" done to a host is that the process will take as much CPU as it can get. This is really only a problem in Xen because the device model is in Domain-0. Once the device model is in a different domain, it doesn't matter anymore as the normal scheduler parameters can be used to ensure that no other hosts are harmed. Regards, Anthony Liguori > Cheers, From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] Recursion in cpu_physical_memory_rw Date: Wed, 15 Nov 2006 13:03:34 -0600 Message-ID: <455B6486.8080604@us.ibm.com> References: <20061115004350.GA21745@gondor.apana.org.au> <200611150057.27235.paul@codesourcery.com> <20061115025839.GA22608@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20061115025839.GA22608@gondor.apana.org.au> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Herbert Xu Cc: Xen Development Mailing List , qemu-devel@nongnu.org List-Id: xen-devel@lists.xenproject.org Herbert Xu wrote: > On Wed, Nov 15, 2006 at 12:57:24AM +0000, Paul Brook wrote: >> 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. > > I'm not suggesting that we change all existing users of cpu_physical_* > to a new interface that only accessed RAM. However, for cases where it > is obvious that only system RAM is intended (e.g., rtl8139), it makes > sense to bypass MMIO handlers. > >> 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. > > The scenario here is a compromised guest attempting to harm a host such > as Xen. The only "harm" done to a host is that the process will take as much CPU as it can get. This is really only a problem in Xen because the device model is in Domain-0. Once the device model is in a different domain, it doesn't matter anymore as the normal scheduler parameters can be used to ensure that no other hosts are harmed. Regards, Anthony Liguori > Cheers,