>
> ----- Original Message -----
> > Hi Dave,
> >
> > In my develop enviroment, kaslr offset will be stored in SoC on-chip memory
> > for debuging, but crash utility is not work if i only set kaslr offset by
> > command '--kaslr XXX', it also need correct kimage_voffset.
> >
> > error message without the patch:
> >
> > VA_BITS: 39
> > using 40000000 as phys_offset
> > kimage_voffset: 0
> > phys_offset: 40000000
> > .....cut....
> > <readmem: ffffff9381e074a0, KVADDR, "cpu_possible_mask", 8, (FOE),
> > 7fffce0dfa48>
> > <read_ramdump: addr: ffffff9381e074a0 paddr: 13b9e074a0 cnt: 8>
> > read_ramdump: READ_ERROR: offset not found for paddr: 13b9e074a0
> > crash: read error: kernel virtual address: ffffff9381e074a0 type:
> > "cpu_possible_mask"
> >
> > This patch add a function to auto calculate kimage_voffset by kaslr offset.
> > Please review it.
> >
> > Thanks,
> > Yueyi Li
> > Hello Yueyi,
> >
> > I have a few questions about this patch.
> >
> > First, can you clarify the kernel version and the dumpfile type that
> > you are trying to address?
> >
> > I understand the confusion, given that arm64 kdump/KASLR support is still
> > being
> > debated upstream. Eventually, arm64 kdump-generated dumpfiles will have
> > "NUMBER(kimage_voffset)" and "NUMBER(PHYS_OFFSET)" VMCOREINFO entries, which
> > will simplify things significantly (and you can see that the crash utility
> > already has support for them in advance).
> Actually, i use crash utility to analysis Android device crash, Linux kernel
> version is 4.4. The ramdump file is not generated by kdump, it is whole DDR
> SDRAM snapshot collected by another RTOS, so i don`t have vmcoreinfo to get
> kimage_voffset & phys_offset. I my opinion, only set kaslr offset should work
> well even if without vmcore file and kimage_voffse, it looks more reasonable.
> > It seems that this patch would only be applicable when looking at an ELF
> > dumpfile, given that your arch_calc_kimage_voffset() function calls
> > arm_kdump_phys_base() -- which only applies if you are looking at an
> > ELF dumpfile:
> >
> > +static void
> > +arm64_calc_kimage_voffset(void)
> > +{
> > + struct machine_specific *ms = machdep->machspec;
> > + ulong kimage_offset;
> > + ulong phys_offset;
> > + struct syment *sp;
> > +
> > + if (machdep->flags & KIMG_VOFFSET) /* --machdep override */
> > + return;
> > +
> > + if ((kt->flags2 & KASLR) && (kt->flags & RELOC_SET)){
> > + arm_kdump_phys_base(&phys_offset);
> > + ms->kimage_voffset = ms->vmalloc_start_addr + (kt->relocate
> > * -1) - phys_offset;
> > + }
> > +
> > +}
> >
> > Is that correct? And if so, why not call arm64_kdump_phys_base() instead?
> > Because I see in your "error message without the patch" above, the
> > phys_base
> > seems to have been calculated correctly to be 40000000, so it looks like
> > the
> > call from arm64_calc_phys_offset() to arm64_kdump_phys_base() must have
> > worked.
> > (since arm64_kdump_phys_base() ultimately calls arm_kdump_phys_base() if
> > nothing
> > else works)
> >
> > So what would happen if you called arm64_calc_phys_offset() *before* your
> > new
> > function? Wouldn't it correctly determine phys_offset? And then there
> > would
> > be no need for you to call it in your new function:
> >
> > @@ -324,6 +325,9 @@ arm64_init(int when)
> > machdep->init_kernel_pgd = arm64_init_kernel_pgd;
> >
> > /* use machdep parameters */
> > + arm64_calc_kimage_voffset();
> > +
> > + /* use machdep parameters */
> > arm64_calc_phys_offset();
> When kernel ASLR is enabled on arm64, the kernel image start address
> can be randomized, phys_offset is no more equal the start address of
> first memory block. It means, arm_kdump_phys_base() can not calculate
> correctly address, we need kimage_voffset to calculate correctly
> phys_offset, this is what arm64_calc_phys_offset() to do( just on
> live system & ELF ramdump). So arm64_calc_kimage_voffset() should be
> called first. This is why crash utility is not work if '-m kimage_voffset'
> is not given.
>
> debug log with the patch, kaslr offset is 0x1378e00000, start address of
> first memory block is 0x40000000:
> readmem: read_ramdump()
>
> VA_BITS: 39
>
> using ffffffd340000000 as phys_offset
>
> kimage_voffset: ffffff9340e00000
>
> phys_offset: ffffffd340000000
>
> gdb vmlinux
>
> GNU gdb (GDB) 7.6
>
> Copyright (C) 2013 Free Software Foundation, Inc.
>
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>
> This is free software: you are free to change and redistribute it.
>
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
>
> and "show warranty" for details.
>
> This GDB was configured as "--host=x86_64-unknown-linux-gnu
> --target=aarch64-elf-linux"...
>
>
> cpu_possible_mask: cpus: 0 1 2 3 4 5 6 7
>
> cpu_present_mask: cpus: 0 1 2 3 4 5 6 7
>
> cpu_online_mask: cpus: 0 1 2 3 4 5 6
>
> cpu_active_mask: cpus: 0 1 2 3 4 5 6
>
> xtime timespec.tv_sec: 58c27009: Fri Mar 10 17:21:13 2017
>
> utsname:
>
> sysname: Linux
>
> nodename: localhost
>
> release: 4.4.21-perf-g5ec6736-00564-gbdc7dcf
>
> version: #1 SMP PREEMPT Wed Mar 8 23:02:12 CST 2017
>
> machine: aarch64
>
> domainname: localdomain
>
>
> > In addition, arm64_calc_phys_offset() also tries to determine the
> > phys_offset value
> > for compressed kdump dumpfiles and live systems. If the dumpfile has been
> > compressed (by the makedumpfile facility), or if you are running on a live
> > system,
> > then your patch would fail to determine phys_offset. But if you were to
> > call
> > arm64_calc_phys_offset() instead, it would call diskdump_phys_base() for
> > compressed
> > dumpfiles, or try to determine the phys_offset value from /proc/iomem on
> > live
> > systems.
> >
> > Dave
> >
> >
> I'm not familar with compressed dumpfiles, just add a judgment in my
> function.
> For live system, if kimage_voffset has been calculated,
> arm64_calc_phys_offset
> will use it calculate correctly phys_offset instead of read from /proc/iomem.
>
> if ((machdep->flags & NEW_VMEMMAP) &&
> ms->kimage_voffset && (sp =
> kernel_symbol_search("memstart_addr"))) {
> paddr = sp->value - machdep->machspec->kimage_voffset;
> if (READMEM(pc->mfd, &phys_offset, sizeof(phys_offset),
> sp->value, paddr) > 0) {
> ms->phys_offset = phys_offset;
> return;
> }
> }
>
> I have attached patch v2, Could you please review it?
>
> Thanks,
> Yueyi Li
> From 10d9a7879589888c8ffe24e8245062115dc16f1e Mon Sep 17 00:00:00 2001
> From: Yueyi Li <liyueyi live com>
> Date: Tue, 14 Mar 2017 21:25:21 +0800
> Subject: [PATCH] [ARM64][patch] Auto calculate kimage_voffset by kaslr offset
>
> ARM64 kimage_voffset can be calculated if kernel ASLR offset is known.
> Add a function to auto calculate kimage_voffset when '--kaslr=<offset>'
> was set.
> ---
> arm64.c | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/arm64.c b/arm64.c
> index 6eaf96d..b51b826 100644
> --- a/arm64.c
> +++ b/arm64.c
> @@ -27,6 +27,7 @@
> static struct machine_specific arm64_machine_specific = { 0 };
> static int arm64_verify_symbol(const char *, ulong, char);
> static void arm64_parse_cmdline_args(void);
> +static void arm64_calc_kimage_voffset(void);
> static void arm64_calc_phys_offset(void);
> static void arm64_calc_virtual_memory_ranges(void);
> static int arm64_kdump_phys_base(ulong *);
> @@ -324,6 +325,9 @@ arm64_init(int when)
> machdep->init_kernel_pgd = arm64_init_kernel_pgd;
>
> /* use machdep parameters */
> + arm64_calc_kimage_voffset();
> +
> + /* use machdep parameters */
> arm64_calc_phys_offset();
>
> if (CRASHDEBUG(1)) {
> @@ -735,6 +739,23 @@ arm64_parse_cmdline_args(void)
> }
> }
>
> +static void
> +arm64_calc_kimage_voffset(void)
> +{
> + struct machine_specific *ms = machdep->machspec;
> + ulong phys_offset;
> +
> + if (ms->kimage_voffset) /* vmcoreinfo or --machdep override */
> + return;
> +
> + if (DISKDUMP_DUMPFILE())
> + return;
> + else if ((kt->flags2 & KASLR) && (kt->flags & RELOC_SET)){
> + arm_kdump_phys_base(&phys_offset); /*get start address of
> first memory block*/
> + ms->kimage_voffset = ms->vmalloc_start_addr + (kt->relocate *
> -1) - phys_offset;
> + }
> +
> +}
In addition to DISKUMP_DUMPFILE(), it also needs to return on live systems
and any other dumpfile type. I need to see your pc->flags and pc->flags2
settings to see how your dumpfile is recognized -- what do you see when you
run this command against your RAM dump?:
crash> help -p | grep -A3 " flags:" | head -3
flags: 1010000210c06
(RUNTIME|TTY|HASH|SCROLL|GDB_INIT|READLINE|KDUMP|DATADEBUG)
flags2: 100400 (VMCOREINFO|REDZONE)
crash>
Thanks,
Dave
--
Crash-utility mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/crash-utility
