[Crash-utility] [PATCH v2 3/3] Automatically detect kernel aslr offset.

[Dave Anderson]

----- Original Message -----

> > Right, it would be nice if the KERNELOFFSET vmcoreinfo item had gone into
> > the kernel at the same time as kALSR.  I see that it's not in Linus' tree
> > yet -- has it been accepted into any other tree waiting to be pulled?
> >
> > Anyway, for that reason, I like the idea of the --kaslr=auto option, and
> > maybe setting a flag somewhere, say in st->flags.  And when the KERNELOFFSET
> > item does eventually show up, the same flag could be set during the initial
> > scan of the dumpfile header, obviating the need for --kaslr.
> >
> > Which reminds me -- the "SYMBOL(_stext)" check that you make in is_netdump()
> > also has to be done in is_diskdump() as well.  Currently makedumpfile does
> > not work with kaslr dumpfiles, but they will eventually get it working.
> >
> 
> Sounds good to me, I'll do that.  I'll check with kees on the
> KERNELOFFSET patch status.

OK.

> >>
> >> > BTW, even though the kernel code seems to indicate that this feature would be
> >> > applicable to 32-bit x86, should I restrict the man page and help data to indicate
> >> > it only applies to x86_64?
> >>
> >> I tried to make it only apply to x86_64, which is why the drive_kaslr_offset 
> >> function call is within a machine_type("X86_64") if clause.
> >> thanks,
> >> Andy
> >
> > But the manual setting of --kalsr=<offset> would still be passed through
> > for 32-bit x86, correct?  Maybe just --kaslr=auto could be restricted?
> >
> Yes, the manual setting of --kaslr would work with 32-bit x86, but it
> probably shouldn't be used that way.  I like the idea of restricting
> the man page.  I don't think it's worth checking to make sure it's not
> set on a 32-bit kernel, but I can add that if you prefer.

I personally don't really care that much, given that Red Hat no longer 
supports x86 kernels.  But it seems like the 32-bit x86 code should either
accept both --kalsr options or neither of them.  And eventually when 
somebody gets around to testing this stuff on 32-bit, we can open the 
door to supporting x86.

One other thing -- this is pretty ugly:

  WARNING: kernel relocated [17592186044032MB]: patching 55431 gdb minimal_symbol values
 
It makes sense with a positive --reloc MB value, but in the case of --kaslr the
message should change the displayed value back to the positive input argument.

Thanks,
  Dave