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
