WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [Qemu-devel] Recursion in cpu_physical_memory_rw

To: Paul Brook <paul@xxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [Qemu-devel] Recursion in cpu_physical_memory_rw
From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Wed, 15 Nov 2006 13:58:39 +1100
Cc: Xen Development Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>, qemu-devel@xxxxxxxxxx
Delivery-date: Tue, 14 Nov 2006 18:59:07 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <200611150057.27235.paul@xxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20061115004350.GA21745@xxxxxxxxxxxxxxxxxxx> <200611150057.27235.paul@xxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
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.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel