From: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: joro@8bytes.org, paul@codesourcery.com, avi@redhat.com,
kvm@vger.kernel.org, qemu-devel@nongnu.org
Subject: Re: Status update
Date: Fri, 2 Jul 2010 20:05:12 +0300 [thread overview]
Message-ID: <20100702170512.GA6809@localhost> (raw)
In-Reply-To: <AANLkTinZ6TlNB71KTH9CjhH3wTn4TuAZ5wbceg-Kue4-@mail.gmail.com>
On Fri, Jul 02, 2010 at 09:03:39AM +0100, Stefan Hajnoczi wrote:
> > 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
Real, non-IOMMU aware hardware looks like this (simplified):
Device <-> IOMMU <-> Memory (1)
Most QEMU translated devices would do exactly that. But AIO is something
like this:
Device + <---translation--- IOMMU (2)
^
|
---------R/W--------> Memory
There are two reasons this form isn't reducible to the former in case of
AIO:
1. It uses cpu_physical_memory_map().
2. The actual I/O happens on a separate thread.
Real hardware of form (1) has no problems since all access is serialized
through the IOMMU. That doesn't mean mapping updates happen instantly.
But software can wait (and be notified) for the updates to happen.
Real hardware of form (2) is comprised of devices which have their own
IOTLB, I think. But unlike cpu_physical_memory_map() in software-land,
these mappings can be updated during I/O. (These devices are
necessarily IOMMU-aware.)
As I see it, this mmaping trick is quite crucial to AIO and I'm not sure
there's a way around it. The solution I proposed is making the IOMMU
wait* for AIO to finish. Perhaps we can also break mmaping into smaller
chunks so they complete in a reasonable time.
* - Waiting here means to delay notifying the guest OS that invalidation
commands completed. This is the important part: if the guest is told the
mappings have been updated, then they really have to be.
Eduard
WARNING: multiple messages have this Message-ID (diff)
From: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
To: Stefan Hajnoczi <stefanha@gmail.com>
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 20:05:12 +0300 [thread overview]
Message-ID: <20100702170512.GA6809@localhost> (raw)
In-Reply-To: <AANLkTinZ6TlNB71KTH9CjhH3wTn4TuAZ5wbceg-Kue4-@mail.gmail.com>
On Fri, Jul 02, 2010 at 09:03:39AM +0100, Stefan Hajnoczi wrote:
> > 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
Real, non-IOMMU aware hardware looks like this (simplified):
Device <-> IOMMU <-> Memory (1)
Most QEMU translated devices would do exactly that. But AIO is something
like this:
Device + <---translation--- IOMMU (2)
^
|
---------R/W--------> Memory
There are two reasons this form isn't reducible to the former in case of
AIO:
1. It uses cpu_physical_memory_map().
2. The actual I/O happens on a separate thread.
Real hardware of form (1) has no problems since all access is serialized
through the IOMMU. That doesn't mean mapping updates happen instantly.
But software can wait (and be notified) for the updates to happen.
Real hardware of form (2) is comprised of devices which have their own
IOTLB, I think. But unlike cpu_physical_memory_map() in software-land,
these mappings can be updated during I/O. (These devices are
necessarily IOMMU-aware.)
As I see it, this mmaping trick is quite crucial to AIO and I'm not sure
there's a way around it. The solution I proposed is making the IOMMU
wait* for AIO to finish. Perhaps we can also break mmaping into smaller
chunks so they complete in a reasonable time.
* - Waiting here means to delay notifying the guest OS that invalidation
commands completed. This is the important part: if the guest is told the
mappings have been updated, then they really have to be.
Eduard
next prev parent reply other threads:[~2010-07-02 17:06 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-29 17:25 Status update Eduard - Gabriel Munteanu
2010-06-29 17:25 ` [Qemu-devel] " Eduard - Gabriel Munteanu
2010-06-30 8:37 ` Stefan Hajnoczi
2010-06-30 8:37 ` [Qemu-devel] " Stefan Hajnoczi
2010-07-01 19:30 ` Eduard - Gabriel Munteanu
2010-07-01 19:30 ` [Qemu-devel] " Eduard - Gabriel Munteanu
2010-07-02 8:03 ` Stefan Hajnoczi
2010-07-02 8:03 ` [Qemu-devel] " Stefan Hajnoczi
2010-07-02 9:41 ` Isaku Yamahata
2010-07-02 9:41 ` Isaku Yamahata
2010-07-02 17:17 ` Eduard - Gabriel Munteanu
2010-07-02 17:17 ` Eduard - Gabriel Munteanu
2010-07-02 17:05 ` Eduard - Gabriel Munteanu [this message]
2010-07-02 17:05 ` Eduard - Gabriel Munteanu
-- strict thread matches above, loose matches on Subject: below --
2014-10-03 12:01 Status Update Richard Purdie
2014-04-29 8:49 Richard Purdie
2014-04-29 11:29 ` Richard Purdie
2014-04-29 17:31 ` Otavio Salvador
2014-04-15 18:45 Richard Purdie
2014-04-08 12:25 Richard Purdie
2014-04-01 13:51 Richard Purdie
2014-03-24 11:53 Richard Purdie
2014-03-18 13:09 Richard Purdie
2014-03-10 2:20 Richard Purdie
2014-03-10 2:43 ` Robert Yang
2013-07-01 7:01 Richard Purdie
2013-05-28 17:35 Richard Purdie
2013-05-28 19:34 ` Jack Mitchell
2013-05-07 12:45 Richard Purdie
2013-05-07 16:29 ` Trevor Woerner
2013-05-07 17:13 ` Burton, Ross
2013-05-07 17:57 ` Trevor Woerner
2013-05-08 10:35 ` Burton, Ross
2013-05-08 12:46 ` Trevor Woerner
2013-04-29 20:57 Richard Purdie
2013-03-20 23:45 Richard Purdie
2006-12-28 12:25 status update Pam Phillips
2006-12-28 10:38 Connie Copeland
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=20100702170512.GA6809@localhost \
--to=eduard.munteanu@linux360.ro \
--cc=avi@redhat.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=paul@codesourcery.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.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.