Re: Ftrace, KASLR and gdb

[Steven Rostedt <rostedt@goodmis.org>]

On Thu, 9 May 2024 14:44:22 +0200
alexandre.ferrieux@orange.com wrote:

> Hi,
> 
> Ftrace is a jewel to dig into the kernel, be it for troubleshooting, perf tuning 
> or just understanding.
> But when one needs to disassemble the running kernel (eg to move kprobes around 
> in a function, in order to understand a given code path), KASLR makes it 
> impossible for gdb to get useful symbol addresses, even with a debug image.

Really? Can't you just use a function name plus offset? For instance, I
do this all the time:

(gdb) li vfs_write+0xc3
0xffffffff812e2513 is in vfs_write (/work/git/linux-trace.git/fs/read_write.c:592).
587                     return ret;
588             if (count > MAX_RW_COUNT)
589                     count =  MAX_RW_COUNT;
590             file_start_write(file);
591             if (file->f_op->write)
592                     ret = file->f_op->write(file, buf, count, pos);
593             else if (file->f_op->write_iter)
594                     ret = new_sync_write(file, buf, count, pos);
595             else
596                     ret = -EINVAL;

(gdb) disass 0xffffffff812e2513
[..]
   0xffffffff812e250e <+190>:   call   0xffffffff82202bc0 <__x86_indirect_thunk_array>
   0xffffffff812e2513 <+195>:   mov    %rax,%r12
   0xffffffff812e2516 <+198>:   test   %r12,%r12
   0xffffffff812e2519 <+201>:   jg     0xffffffff812e257c <vfs_write+300>


And I can add a kprobe the same way:

 # cd /sys/kernel/tracing
 # echo 'p:write vfs_write+0xc3 a=%ax' > kprobe_events
 # trace-cmd start -e write
 # trace-cmd show
[..]
       trace-cmd-884     [006] d.Z..   563.447396: write: (vfs_write+0xc3/0x2b0) a=0x1
  NetworkManager-461     [000] d.Z..   564.791375: write: (vfs_write+0xc3/0x2b0) a=0x8
  NetworkManager-461     [000] d.Z..   564.791408: write: (vfs_write+0xc3/0x2b0) a=0x8


> That said, /proc/kallsyms always gives the accurate, present symbol addresses. 
> But, to my knowledge, gdb isn't able to import /proc/kallsyms as a symbol table.
> To circumvent this, I've written a small userland tool, usling libbfd, that 
> creates an ELF file out of /proc/kallsyms. Passing this ELF file to gdb instead 
> of "vmlinux", and /proc/kcore as core, then allows for a perfect gdb session on 
> the running kernel. Of course this ELF file is only valid until the next reboot, 
> but that's okay as its creation is fast.
> 
> Now, my question: did I miss an alternative ?
> 
> In other words, is there some kind of "kallsyms plug-in" for gdb somewhere ?
> Or, taking the problem from the other side, some kernel module exposing a 
> "/proc/kallsyms.elf" or similar, for direct consumption by gdb ?
> Or another method, that people routinely use for the same purpose ?
> 

Do you need the absolute address? Can't you just use the offset of functions?

-- Steve