From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35139) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6ew5-0000mH-IY for qemu-devel@nongnu.org; Tue, 15 Nov 2016 09:42:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c6ew0-0004m8-MR for qemu-devel@nongnu.org; Tue, 15 Nov 2016 09:42:09 -0500 Received: from mx5-phx2.redhat.com ([209.132.183.37]:33206) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c6ew0-0004lR-Es for qemu-devel@nongnu.org; Tue, 15 Nov 2016 09:42:04 -0500 Date: Tue, 15 Nov 2016 09:41:48 -0500 (EST) From: Dave Anderson Message-ID: <1751581928.15336894.1479220908854.JavaMail.zimbra@redhat.com> In-Reply-To: References: <20161109030146.GA3802@dhcp-128-65.nay.redhat.com> <20161109104059.bvw5h4k4v77pw2rl@kamzik.brq.redhat.com> <1985884093.14085561.1478705300645.JavaMail.zimbra@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: Paolo Bonzini Cc: Andrew Jones , bhe@redhat.com, Dave Young , qemu-devel@nongnu.org, qiaonuohan@cn.fujitsu.com, lersek@redhat.com ----- Original Message ----- > > > 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? Yes, sorry, that's correct -- that's what the code does, and what I meant to express... Dave > 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 >