[Crash-utility] [ARM64][patch v5] Auto calculate kimage_voffset by kaslr offset

Dave Anderson anderson at redhat.com
Fri Mar 17 20:27:33 UTC 2017



----- Original Message -----
> 
> On 2017/3/17 22:25, Dave Anderson wrote:
> >
> > ----- Original Message -----
> >> However, that is why I am interested in your live system initialization
> >> of kimage_voffset -- for live system access using /dev/mem, /proc/kcore,
> >> or an older version of the /dev/crash driver that did not have the ioctl()
> >> to read kimage_voffset.  But, in order to do that, arm64_calc_kimage_voffset()
> >> needs to be able to handle all /proc/iomem cases to correctly calculate
> >> PHYS_OFFSET.
> >
> > Or better stated, your arm64_calc_kimage_voffset() needs to be able to handle all
> > /proc/iomem cases to correctly calculate kimage_voffset.  Because on the 4.8
> > kernel, it does not work.
>
> Dave,
> 
> Sorry for my misunderstanding of PHYS_OFFSET,  actually kimage_voffset
> is the offset between kernel virtual address and physical address. So,
> to calculate it need find out which physical address is mapping to
> VA_START, not PHYS_OFFSET.
> 
> Please check patch v5, it should be OK for live system.
> 
> Thanks,
> Yueyi


Yueyi,

Yes, thanks, this patch does select the correct "offset" for 
use by your calculation.  On both the 4.8 and 4.10 kernels, 
the System RAM segment at 0x4000200000 is selected.

However, I wonder if it would be simpler to just select the
System RAM segment that *contains* the "Kernel code" segment, 
which would follow it in /proc/iomem:

4.8 kernel:
  
  4000000000-40001fffff : System RAM
  4000200000-43fa59ffff : System RAM
    4000280000-4000c7ffff : Kernel code
    4000d90000-400166ffff : Kernel data
  43fa5a0000-43fa9dffff : System RAM
  43fa9e0000-43ff99ffff : System RAM
  43ff9a0000-43ff9affff : System RAM
  43ff9b0000-43ff9bffff : System RAM
  43ff9c0000-43ff9effff : System RAM
  43ff9f0000-43ffffffff : System RAM
  
4.10 kernel:
  
  4000000000-40001fffff : reserved
  4000200000-4001ffffff : System RAM
    4000280000-4000ccffff : Kernel code
    4000e00000-40016effff : Kernel data
  40023b0000-4ff733ffff : System RAM
  4ff7340000-4ff77cffff : reserved
  4ff77d0000-4ff792ffff : System RAM
  4ff7930000-4ff7e7ffff : reserved
  4ff7e80000-4ff7e8ffff : System RAM
  4ff7e90000-4ff7efffff : reserved
  4ff7f10000-4ff800ffff : reserved
  4ff8010000-4fffffffff : System RAM

In other words, just walk through the /proc/iomem entries, saving
the System RAM start address as you go.  Then when "Kernel code" is
found, use the last RAM start address.

And a couple other things...

For backwards compatibility (i.e., kernels without kimage_voffset), 
the call from arm64_init() should be conditional like this:

	if (machdep->flags & NEW_VMEMMAP)
               arm64_calc_kimage_voffset();

And for live systems without /dev/crash, it wouldn't be necessary to 
add "--kaslr=0" to the command line if arm64_calc_kimage_voffset() started
something like this:

  static void
  arm64_calc_kimage_voffset(void)
  {
          struct machine_specific *ms = machdep->machspec;
          ulong offset;
  
          if (ms->kimage_voffset) /* vmcoreinfo, --machdep override, or ioctl */
                  return;
  
          if (DUMPFILE()) {
                  if (!(kt->flags2 & KASLR) || !(kt->flags & RELOC_SET))
                          return;
          }
  ...
  
What do you think?

Thanks, 
  Dave




More information about the Crash-utility mailing list