qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] virsh dump (qemu guest memory dump?): KASLR enabled lin


From: Paolo Bonzini
Subject: Re: [Qemu-devel] virsh dump (qemu guest memory dump?): KASLR enabled linux guest support
Date: Mon, 14 Nov 2016 11:41:47 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]