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 > <eduard.munteanu@xxxxxxxxxxx> 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@xxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
