From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50833) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c4Unk-00024n-A8 for qemu-devel@nongnu.org; Wed, 09 Nov 2016 10:28:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c4Ung-0004kJ-CD for qemu-devel@nongnu.org; Wed, 09 Nov 2016 10:28:36 -0500 Received: from mx5-phx2.redhat.com ([209.132.183.37]:55057) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c4Ung-0004jv-4Z for qemu-devel@nongnu.org; Wed, 09 Nov 2016 10:28:32 -0500 Date: Wed, 9 Nov 2016 10:28:20 -0500 (EST) From: Dave Anderson Message-ID: <1985884093.14085561.1478705300645.JavaMail.zimbra@redhat.com> In-Reply-To: <20161109104059.bvw5h4k4v77pw2rl@kamzik.brq.redhat.com> References: <20161109030146.GA3802@dhcp-128-65.nay.redhat.com> <20161109104059.bvw5h4k4v77pw2rl@kamzik.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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 Cc: Dave Young , wency@cn.fujitsu.com, qiaonuohan@cn.fujitsu.com, lersek@redhat.com, qemu-devel@nongnu.org, bhe@redhat.com ----- Original Message ----- > 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. > > Thanks, > drew I'm not sure whether this "guest userspace agent" is still in play here, but if there were such a thing, it could theoretically do the same thing that crash currently does when running on a live system. Two basic necessities are are needed, whether running live or against a dumpfile: (1) the CONFIG_RANDOMIZE_BASE relocation value that modifies the kernel virtual address range compiled into the vmlinux file, which starts at the hardwired __START_KERNEL_map address. (2) the contents of the kernel's "phys_base" symbol. Both of those are available or calculatable from the contents of a kdump header. However, on a live system, it's done like this: - /proc/kallsyms is queried for the symbol value of "_text", which would be relocated if KASLR is in play. That value is compared against the "_text" symbol value compiled into the vmlinux file to determine the relocation value generated by CONFIG_RANDOMIZE_BASE. Given that relocation value, and before any kernel memory is accessed, crash goes in a backdoor into its embedded gdb module, and modifies the data structures of all kernel symbols, applying the relocation value. Once that's done, in order to read kernel symbols from the statically-mapped kernel region based at __START_KERNEL_map, it translates a (possibly relocated) kernel virtual address into a physical address like this: physical-address = virtual-address - __START_KERNEL_map + phys_base But it's a chicken-and-egg deal, because the contents of the "phys_base" symbol are needed to calculate the physical address, but it can't read the "phys_base" symbol contents without first knowing its contents. So on a live system, the "phys_base" is calculated by reading the "Kernel Code:" value from /proc/iomem, and then doing this: phys_base = [Kernel Code: value] - ["_text" symbol value] - __START_KERNEL_map So theoretically, the guest agent could read /proc/iomem and /proc/kallsyms for the information required. (I think...) Dave