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? > > 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). > > * 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. Thanks Wen Congyang