From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57460) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDmuO-0000fQ-KK for qemu-devel@nongnu.org; Mon, 17 Sep 2012 21:47:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TDmuN-00049c-Fh for qemu-devel@nongnu.org; Mon, 17 Sep 2012 21:47:28 -0400 Received: from [222.73.24.84] (port=56476 helo=song.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDmuN-00046h-5b for qemu-devel@nongnu.org; Mon, 17 Sep 2012 21:47:27 -0400 Message-ID: <5057D3F1.20005@cn.fujitsu.com> Date: Tue, 18 Sep 2012 09:52:49 +0800 From: Wen Congyang MIME-Version: 1.0 References: <20120917145622.5ba28e23@doriath.home> In-Reply-To: <20120917145622.5ba28e23@doriath.home> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 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: Luiz Capitulino Cc: Jan Kiszka , Marcelo Tosatti , Eric Blake , Markus Armbruster , qemu-devel 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