From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45919) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c4R1O-0000fg-Mu for qemu-devel@nongnu.org; Wed, 09 Nov 2016 06:26:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c4R1K-0004oX-LZ for qemu-devel@nongnu.org; Wed, 09 Nov 2016 06:26:26 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34444) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c4R1K-0004nu-Cx for qemu-devel@nongnu.org; Wed, 09 Nov 2016 06:26:22 -0500 References: <20161109030146.GA3802@dhcp-128-65.nay.redhat.com> <20161109104059.bvw5h4k4v77pw2rl@kamzik.brq.redhat.com> From: Laszlo Ersek Message-ID: <9144d6b1-a1c9-e727-4673-9df10b227fdb@redhat.com> Date: Wed, 9 Nov 2016 12:26:17 +0100 MIME-Version: 1.0 In-Reply-To: <20161109104059.bvw5h4k4v77pw2rl@kamzik.brq.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] virsh dump (qemu guest memory dump?): KASLR enabled linux guest support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrew Jones , Dave Young Cc: wency@cn.fujitsu.com, qiaonuohan@cn.fujitsu.com, anderson@redhat.com, qemu-devel@nongnu.org, bhe@redhat.com On 11/09/16 11:40, Andrew Jones wrote: > On Wed, Nov 09, 2016 at 11:01:46AM +0800, Dave Young wrote: >> Hi, >> >> Latest linux kernel enabled kaslr to randomiz phys/virt memory >> addresses, we had some effort to support kexec/kdump so that crash >> utility can still works in case crashed kernel has kaslr enabled. >> >> But according to Dave Anderson virsh dump does not work, quoted messages >> from Dave below: >> >> """ >> with virsh dump, there's no way of even knowing that KASLR >> has randomized the kernel __START_KERNEL_map region, because there is no >> virtual address information -- e.g., like "SYMBOL(_stext)" in the kdump >> vmcoreinfo data to compare against the vmlinux file symbol value. >> Unless virsh dump can export some basic virtual memory data, which >> they say it can't, I don't see how KASLR can ever be supported. >> """ >> >> I assume virsh dump is using qemu guest memory dump facility so it >> should be first addressed in qemu. Thus post this query to qemu devel >> list. If this is not correct please let me know. >> >> Could you qemu dump people make it work? Or we can not support virt dump >> as long as KASLR being enabled. Latest Fedora kernel has enabled it in x86_64. >> > > When the -kernel command line option is used, then it may be possible > to extract some information that could be used to supplement the memory > dump that dump-guest-memory provides. However, that would be a specific > use. In general, QEMU knows nothing about the guest kernel. It doesn't > know where it is in the disk image, and it doesn't even know if it's > Linux. > > Is there anything a guest userspace application could probe from e.g. > /proc that would work? If so, then the guest agent could gain a new > feature providing that. I fully agree. This is exactly what I suggested too, independently, in the downstream thread, before arriving at this upstream thread. Let me quote that email: On 11/09/16 12:09, Laszlo Ersek wrote: > [...] the dump-guest-memory QEMU command supports an option called > "paging". Here's its documentation, from the "qapi-schema.json" source > file: > >> # @paging: if true, do paging to get guest's memory mapping. This allows >> # using gdb to process the core file. >> # >> # IMPORTANT: this option can make QEMU allocate several gigabytes >> # of RAM. This can happen for a large guest, or a >> # malicious guest pretending to be large. >> # >> # Also, paging=true has the following limitations: >> # >> # 1. The guest may be in a catastrophic state or can have corrupted >> # memory, which cannot be trusted >> # 2. The guest can be in real-mode even if paging is enabled. For >> # example, the guest uses ACPI to sleep, and ACPI sleep state >> # goes in real-mode >> # 3. Currently only supported on i386 and x86_64. >> # > > "virsh dump --memory-only" sets paging=false, for obvious reasons. > > [...] the dump-guest-memory command provides a raw snapshot of the > virtual machine's memory (and of the registers of the VCPUs); it is > not enlightened about the guest. > > If the additional information you are looking for can be retrieved > within the running Linux guest, using an appropriately privieleged > userspace process, then I would recommend considering an extension to > the qemu guest agent. The management layer (libvirt, [...]) could > first invoke the guest agent (a process with root privileges running > in the guest) from the host side, through virtio-serial. The new guest > agent command would return the information necessary to deal with > KASLR. Then the management layer would initiate the dump like always. > Finally, the extra information would be combined with (or placed > beside) the dump file in some way. > > So, this proposal would affect the guest agent and the management > layer (= libvirt). Given that we already dislike "paging=true", enlightening dump-guest-memory with even more guest-specific insight is the wrong approach, IMO. That kind of knowledge belongs to the guest agent. Thanks Laszlo