Re: [Qemu-devel] qmp: dump-guest-memory: -p option has issues, fix it or drop it?

[HATAYAMA Daisuke]

From: Luiz Capitulino <address@hidden>
Subject: Re: [Qemu-devel] qmp: dump-guest-memory: -p option has issues, fix it 
or drop it?
Date: Wed, 19 Sep 2012 10:23:26 -0300

> On Wed, 19 Sep 2012 11:26:51 +0900 (JST)
> HATAYAMA Daisuke <address@hidden> wrote:
> 
>> From: Wen Congyang <address@hidden>
>> Subject: Re: [Qemu-devel] qmp: dump-guest-memory: -p option has issues, fix 
>> it or drop it?
>> Date: Wed, 19 Sep 2012 10:07:04 +0800
>> 
>> > At 09/19/2012 08:18 AM, Luiz Capitulino Wrote:
>> >> On Tue, 18 Sep 2012 16:13:30 -0500
>> >> Anthony Liguori <address@hidden> wrote:
>> >> 
>> >>> Markus Armbruster <address@hidden> writes:
>> >>>
>> >>>> Jan Kiszka <address@hidden> writes:
>> >>>>

>> How about dropping making a whole list of memory maps at the same
>> time, and how about rewriting the code so that it always has at most
>> one memory mapping by merging virtually consequtive chunks? If
>> possible, only 40 bytes is needed.
> 
> It already merges contiguous addresses and addresses that fall in
> the same range. It can also skip addresses due to a few reasons (I/O
> page, not present page, etc), which makes the problem very unlikely
> in practice.
> 

I've noticed this locally, thanks.

> Our concern is with guests intentionally trying to make qemu allocate
> more memory.

My idea is not to create a list of a whole memory mapping. This needs
O(n), which can be a target of attackers. If possible to drop this
list, memory consumption is O(1), and there's no room for any guest to
attack.

Concretely, the processing becomes: first walking page tables to
identify a memory mapping corresponding to a PT_LOAD entry, then write
it when reaching the part belonging to a next PT_LOAD entry.

But the problem I've noticed just now..., is that then we need to walk
page tables twice: first for writing program header tables and second
for writing memory part. Code becomes not clean.

Thanks.
HATAYAMA, Daisuke