All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Cc: Xen Development Mailing List <xen-devel@lists.xensource.com>,
	Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: [Qemu-devel] Recursion in cpu_physical_memory_rw
Date: Wed, 15 Nov 2006 00:57:24 +0000	[thread overview]
Message-ID: <200611150057.27235.paul@codesourcery.com> (raw)
In-Reply-To: <20061115004350.GA21745@gondor.apana.org.au>

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

WARNING: multiple messages have this Message-ID (diff)
From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Cc: Xen Development Mailing List <xen-devel@lists.xensource.com>,
	Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: Recursion in cpu_physical_memory_rw
Date: Wed, 15 Nov 2006 00:57:24 +0000	[thread overview]
Message-ID: <200611150057.27235.paul@codesourcery.com> (raw)
In-Reply-To: <20061115004350.GA21745@gondor.apana.org.au>

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

  reply	other threads:[~2006-11-15  0:57 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-15  0:43 [Qemu-devel] Recursion in cpu_physical_memory_rw Herbert Xu
2006-11-15  0:43 ` Herbert Xu
2006-11-15  0:57 ` Paul Brook [this message]
2006-11-15  0:57   ` Paul Brook
2006-11-15  2:58   ` [Qemu-devel] " Herbert Xu
2006-11-15  7:55     ` Keir Fraser
2006-11-15  7:57       ` [Xen-devel] " Keir Fraser
2006-11-15 11:12       ` Herbert Xu
2006-11-15 11:12         ` Herbert Xu
2006-11-15 11:25         ` Keir Fraser
2006-11-15 11:52           ` [Xen-devel] " Keir Fraser
2006-11-15 15:02         ` Paul Brook
2006-11-15 15:02           ` [Xen-devel] " Paul Brook
2006-11-16  5:09           ` [Xen-devel] Re: [Qemu-devel] " Herbert Xu
2006-11-16  5:09             ` Herbert Xu
2006-11-15 19:03     ` Anthony Liguori
2006-11-15 19:04       ` Anthony Liguori
2006-11-16  5:11       ` Herbert Xu
2006-11-16  7:52         ` Keir Fraser
2006-11-16  7:53           ` [Xen-devel] " Keir Fraser
2006-11-16  7:59           ` Herbert Xu
2006-11-16  7:59             ` Herbert Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200611150057.27235.paul@codesourcery.com \
    --to=paul@codesourcery.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=qemu-devel@nongnu.org \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.