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
