[Top][All Lists]

[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: Dave Anderson
Subject: Re: [Qemu-devel] virsh dump (qemu guest memory dump?): KASLR enabled linux guest support
Date: Wed, 9 Nov 2016 09:32:43 -0500 (EST)

----- Original Message -----
> 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.
> """

We also need the x86_64 phys_base value.

As it is right now, virsh dump vmcores work by luck.  It is presumed that
the __START_KERNEL_map region is unmodified (i.e., what's in the vmlinux file),
and the phys_base value is guessed by checking phys_base values from 
-16MB to +16MB in 1MB chunks.  If the phys_base value is not one of those
32 possible values, the crash session will fail.


> 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.
> Thanks
> Dave

reply via email to

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