[Crash-utility] [PATCH v2] arm64: fix kernel memory map handling for kaslr-enabled kernel

[Pratyush Anand]

On 27/05/2016:01:03:56 PM, AKASHI Takahiro wrote:
> On Thu, May 26, 2016 at 03:09:55PM +0530, Pratyush Anand wrote:
> > On 26/05/2016:05:13:30 PM, AKASHI Takahiro wrote:
> > > On Wed, May 25, 2016 at 10:28:10AM -0400, Dave Anderson wrote:
> > 
> > [...]
> > 
> > > > > (This is the reason that I don't think we need a VMCOREINFO for
> > > > > CONFIG_RANDOMIZE_BASE.)
> > > > 
> > > > Well, as long as there's a way to avoid that unnecessary/confusing
> > > > warning message for non-KASLR new-vmemmap kernels.
> > > > 
> > > > I also wonder whether makedumpfile could use it?
> > > 
> > > -> Pratyush?
> > 
> > Since  second kernel's initrd cannot include a large file like VMLINUX, so
> > makedumpfile should also work without passing '-x vmlinux'.  Therefore,
> > makedumpfile will need some minimal symbol's values to be passed in vmcore.
> 
> I understand.
> (but I wonder why makedumpfile doesn't utilize System.map nor .config.)

So far makedumpfile has been designed to work only with vmcore as input in it's
minimal form (specially in second kernel).
+Atsushi & makedumpfile list: He will have better idea about it.

Moreover, there are few variables, whose values are needed in order to translate
phys to virt and vice versa. So, passing their symbol address would not be of
much help. For example, we need to know value of kimage_voffset for __pa(), and
so symbol address of kimage_voffset will not help.

> 
> > IIUC, then you need to pass CONFIG_RANDOMIZE_BASE in order to calculate
> > PHYS_OFFSET. If yes, then why not to pass PHYS_OFFSET itself into vmcore.
> 
> No, as I said in the discussions, I don't think that we need
> CONFIG_RANDOMIZE_BASE *if* we can read a kernel symbol's value
> from /proc/vmcore.

What I understand that, we can read only those symbols/variables from vmcore
which have been embedded using VMCOREINFO_xxxx macros (if we do not pass
vmlinux, like in second kernel). Atsushi, please correct me if I am wrong.

> 
> > Following numbers in vmcore [1] is helping me out in implementing __pa() and
> > __va() for all page table sizes and levels.
> > 
> > VMCOREINFO_NUMBER(pgtable_levels);
> > VMCOREINFO_NUMBER(va_bits);
> > VMCOREINFO_NUMBER(page_shift);
> 
> Since We already have VMCOREINFO(PAGESIZE), we won't nedd page_shift.

Yes, agreed.

> As well, pgtable_levels can be determined by va_bits and PAGESIZE.
> See arch/arm64/Kconfig.

Yes, agreed.

> 
> > VMCOREINFO_NUMBER(phys_offset);
> > VMCOREINFO_NUMBER(config_kasan);
> 
> Let me ask some questions.
> * What kind of data in vmcore and how does makedumpfile access
>   without vmlinux nor System.map?

Well, I do not have the deep idea, again Atsushi can help here.

makedumpfile mainly compresses vmcore (ram image of panicked kernel),
additionally it also excludes unnecessary pages for analysis. It will need
symbol information to exclude unnecessary pages, where vmlinux is needed mainly.
So, normally we do not perform erase(exclude) functionality in second kernel. It
is being performed latter, on a compressed dumpfile.

> * Why do you need CONFIG_KASAN?

KASAN_SHADOW_SIZE is dependent on CONFIG_KASAN.
MODULES_VADDR is dependent on KASAN_SHADOW_SIZE.

We need MODULES_VADDR,VMALLOC_START,VMEMMAP_START and their END addresses in
order to define whether a virtual to physical translation can be obtained using
linear mapping or need to read from page table instead.

Thanks for the questions and inputs.  Those are helpful. :-)
~Pratyush
> 
> Thanks,
> -Takahiro AKASHI
> 
> > VMCOREINFO_NUMBER(kimage_voffset);
> > 
> > ~Pratyush
> > 
> > [1]
> > https://github.com/pratyushanand/linux/blob/7011e478aae3e568cc8dca15b6c128fe728416f7/arch/arm64/kernel/machine_kexec.c#L275
> > 
> > --
> > Crash-utility mailing list
> > Crash-utility at redhat.com
> > https://www.redhat.com/mailman/listinfo/crash-utility
> 
> -- 
> Thanks,
> -Takahiro AKASHI
> 
> --
> Crash-utility mailing list
> Crash-utility at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility