Re: [Qemu-devel] Re: Status update

[Isaku Yamahata]

On Fri, Jul 02, 2010 at 09:03:39AM +0100, Stefan Hajnoczi wrote:
> On Thu, Jul 1, 2010 at 8:30 PM, Eduard - Gabriel Munteanu
> <address@hidden> 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
> >> <address@hidden> 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.

In such a case, OS should put device into quiescence by reset like
pci bus reset or pcie function level reset.
pci bus reset patch hasn't been merged yet, though.
It needs clean up/generalization.

> 
> 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
> 

-- 
yamahata