qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: Status update


From: Stefan Hajnoczi
Subject: [Qemu-devel] Re: Status update
Date: Fri, 2 Jul 2010 09:03:39 +0100

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.

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 via email to

[Prev in Thread] Current Thread [Next in Thread]