qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
Cc: qemu-devel@nongnu.org, joro@8bytes.org, paul@codesourcery.com,
	kvm@vger.kernel.org, avi@redhat.com
Subject: [Qemu-devel] Re: Status update
Date: Fri, 2 Jul 2010 09:03:39 +0100	[thread overview]
Message-ID: <AANLkTinZ6TlNB71KTH9CjhH3wTn4TuAZ5wbceg-Kue4-@mail.gmail.com> (raw)
In-Reply-To: <20100701193034.GA7421@localhost>

On Thu, Jul 1, 2010 at 8:30 PM, Eduard - Gabriel Munteanu
<eduard.munteanu@linux360.ro> wrote:
> 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
>> <eduard.munteanu@linux360.ro> 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?
>>
> 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.

As long as QEMU acts in the same way as real hardware we should be
okay.  Will real hardware change the mappings immediately and abort
the DMA from the device if it tries to access an invalidated address?

Stefan

  reply	other threads:[~2010-07-02  8:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-29 17:25 [Qemu-devel] Status update Eduard - Gabriel Munteanu
2010-06-30  8:37 ` [Qemu-devel] " Stefan Hajnoczi
2010-07-01 19:30   ` Eduard - Gabriel Munteanu
2010-07-02  8:03     ` Stefan Hajnoczi [this message]
2010-07-02  9:41       ` Isaku Yamahata
2010-07-02 17:17         ` Eduard - Gabriel Munteanu
2010-07-02 17:05       ` Eduard - Gabriel Munteanu

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=AANLkTinZ6TlNB71KTH9CjhH3wTn4TuAZ5wbceg-Kue4-@mail.gmail.com \
    --to=stefanha@gmail.com \
    --cc=avi@redhat.com \
    --cc=eduard.munteanu@linux360.ro \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=paul@codesourcery.com \
    --cc=qemu-devel@nongnu.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).