From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52191) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6Ei3-00029B-9M for qemu-devel@nongnu.org; Mon, 14 Nov 2016 05:41:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c6Ehy-0001NN-DX for qemu-devel@nongnu.org; Mon, 14 Nov 2016 05:41:55 -0500 Received: from mail-wm0-x242.google.com ([2a00:1450:400c:c09::242]:36256) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c6Ehy-0001N2-6h for qemu-devel@nongnu.org; Mon, 14 Nov 2016 05:41:50 -0500 Received: by mail-wm0-x242.google.com with SMTP id m203so14034955wma.3 for ; Mon, 14 Nov 2016 02:41:50 -0800 (PST) Sender: Paolo Bonzini References: <20161109030146.GA3802@dhcp-128-65.nay.redhat.com> <20161109104059.bvw5h4k4v77pw2rl@kamzik.brq.redhat.com> <1985884093.14085561.1478705300645.JavaMail.zimbra@redhat.com> From: Paolo Bonzini Message-ID: Date: Mon, 14 Nov 2016 11:41:47 +0100 MIME-Version: 1.0 In-Reply-To: <1985884093.14085561.1478705300645.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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: Dave Anderson , Andrew Jones Cc: bhe@redhat.com, Dave Young , qemu-devel@nongnu.org, qiaonuohan@cn.fujitsu.com, lersek@redhat.com On 09/11/2016 16:28, Dave Anderson wrote: > 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. > > 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. > > [...] 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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Should there be parentheses around this? The physical-address formula above is equivalent to phys_base = physical-address - (virtual-address - __START_KERNEL_map) > > So theoretically, the guest agent could read /proc/iomem and /proc/kallsyms > for the information required. (I think...) Then yes, the guest-agent could add a command get-kernel-text-start with an output like: { 'virtual': 0xffffffff86000000, 'physical': 0xb6000000 } and libvirt can expose it to crash. In this case, phys_base would be 0xb0000000 if I did the math right, and the relocation value is obtained by comparing the "virtual" address with the vmlinux "_text". IIRC the guest agent runs as root, so reading /proc/iomem is not a problem. Paolo