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

[Jan Kiszka]

On 2012-09-18 03:52, Wen Congyang wrote:
> At 09/18/2012 01:56 AM, Luiz Capitulino Wrote:
>> Hi Wen,
>>
>> We've re-reviewed the dump-guest-memory command and found some
>> possible issues with the -p option.
>>
>> The main issue is that it seems possible for a malicious guest to set
>> page tables in a way that we allocate a MemoryMapping structure for
>> each possible PTE. If IA-32e paging is used, this could lead to the
>> allocation of dozens of gigabytes by qemu.
>>
>> Of course that this is not expected for the regular case, where a
>> MemoryMapping allocation can be skipped for several reasons  (I/O memory,
>> page not present, contiguous/in same range addresses etc), but the
>> point is what a malicious guest can do.
>>
>> Another problem is that the -p option seems to be broken for SMP guests.
>> The problem is in qemu_get_guest_memory_mapping():
>>
>>     first_paging_enabled_cpu = find_paging_enabled_cpu(first_cpu);
>>     if (first_paging_enabled_cpu) {
>>         for (env = first_paging_enabled_cpu; env != NULL; env = 
>> env->next_cpu) {
>>             ret = cpu_get_memory_mapping(list, env);
>>             if (ret < 0) {
>>                 return -1;
>>             }
>>         }
>>         return 0;
>>     }
>>
>> This looks for the first vCPU with paging enabled, and then assumes
>> that all the following vCPUs also have paging enabled. How does this
>> hold?

cpu_get_memory_mapping re-validates that paging is one. In fact,
cpu_get_memory_mapping should handle both cases so that the generic code
need not worry about paging on/off.

>>
>> Assuming that this last issue is fixable (ie. we can make the -p
>> option work well with SMP guests), we should at least document that
>> -p can make QEMU allocates lots of memory and end up being killed
>> by the OS.
>>
>> However, I also think that we should consider if having the -p
>> feature is really worth it. It's a complex feature and has a number
>> of limitations*. If libvirt doesn't use this, dropping it shouldn't
>> be a big deal (we can return an error when -p is used).

libvirt should surely not be the only reference for debugging features.

>>
>>  * The issues discussed in this email plus the fact that the guest
>>    memory may be corrupted, and the guest may be in real-mode even
>>    when paging is enabled
>>
> 
> Yes, there are some limitations with this option. Jan said that he
> always use gdb to deal with vmcore, so he needs such information.

The point is to overcome the focus on Linux-only dump processing tools.

I'm sure the memory allocation can be avoided by writing out any found
virt->phys mapping directly to the vmcore file. We know where physical
RAM will be, we only need the corresponding virtual addresses - IIUC. So
first prepare the section according to the guest's RAM size and then,
once we identified a page while walking the tables carefully, seek to
that file position and write to it.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux