From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33611) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDu0y-0001fZ-Sv for qemu-devel@nongnu.org; Tue, 18 Sep 2012 05:22:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TDu0s-0004e9-EM for qemu-devel@nongnu.org; Tue, 18 Sep 2012 05:22:44 -0400 Received: from thoth.sbs.de ([192.35.17.2]:22261) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDu0s-0004dp-42 for qemu-devel@nongnu.org; Tue, 18 Sep 2012 05:22:38 -0400 Message-ID: <50583D45.6080200@siemens.com> Date: Tue, 18 Sep 2012 11:22:13 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <20120917145622.5ba28e23@doriath.home> <5057D3F1.20005@cn.fujitsu.com> In-Reply-To: <5057D3F1.20005@cn.fujitsu.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] qmp: dump-guest-memory: -p option has issues, fix it or drop it? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wen Congyang Cc: qemu-devel , Marcelo Tosatti , Eric Blake , Markus Armbruster , Luiz Capitulino 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