----- Original Message -----
>
>
> ----- Original Message -----
>
> >
> > That being said, my recent 4.8 and 4.9 KASLR testing has been on live
> > systems and compressed kdumps, so the old tried-and-true manner of
> > calculating the phys_base from the ELF PT_LOAD segments apparently
> > no longer works with KASLR.
> >
> > It would be so much more helpful if the VMCOREINFO data in the ELF
> > header stored the actual phys_base value instead of its symbol value:
> >
> > crash> help -D
> > ...
> > SYMBOL(phys_base)=ffffffffa740b010
> > ...
> >
> > which is completely useless unless the phys_base value is known.
> >
> > Anyway, can you send me the makedumpfile code that calculates the
> > phys_base value?
> >
> > Dave
>
> As it turns out, the problem with the crash utility is that it has to
> calculate phys_base well before it even knows the kernel has been relocated
> by KASLR. So when it sees the __START_KERNEL_map PT_LOAD segment, it
> mistakes
> it for the kernel modules' virtual address region and skips it.
>
> The kernel has this:
>
> #if defined(CONFIG_RANDOMIZE_BASE)
> #define KERNEL_IMAGE_SIZE (1024 * 1024 * 1024)
> #else
> #define KERNEL_IMAGE_SIZE (512 * 1024 * 1024)
> #endif
>
> and then this:
>
> #define MODULES_VADDR (__START_KERNEL_map + KERNEL_IMAGE_SIZE)
>
> So with KASLR, MODULES_VADDR gets pushed up from the traditional ffffffffa0000000
> up to ffffffffc0000000.
>
> So I'm curious as to what you use in makedumpfile to determine whether
> CONFIG_RANDOMIZE_BASE has been configured?
>
> Thanks,
> Dave
Hey, sorry, I didn't notice that this was added upstream:
commit 1303a27c9c32020a3b6ac89be270d2ab1f28be24
Author: Baoquan He <bhe at redhat.com>
Date: Wed Sep 9 15:39:03 2015 -0700
kexec: export KERNEL_IMAGE_SIZE to vmcoreinfo
With that in place, it will be an easy fix for the crash utility.
Thanks,
Dave
