Re: Ftrace, KASLR and gdb

[Steven Rostedt <rostedt@goodmis.org>]

On Sun, 12 May 2024 00:44:27 +0200
alexandre.ferrieux@orange.com wrote:

> 
> The problem is rather, on the gdb side, with a production kernel (not the one 
> you've just compiled), on a random machine you have a passing access to. First, 
> the kernel itself is compressed (vmlinuz), and in many cases getting the vmlinux 
> is a pain. So, what ELF binary do you pass to gdb ?
> 
> In my case:
> 
>    sym2elf /proc/kallsyms > /tmp/kallsyms.elf
>    gdb /tmp/kallsyms.elf /proc/kcore
>    (gdb) disass vfs_write

Ah, so you are running gdb on the live kernel.

>    ...
> 
> As an added bonus, I see (a snapshot of) globals:
> 
>    (gdb) p *(int *)jiffies
>    $1 = 92299928
> 
> And also I see ftrace's surgical changes if by accident I disassemble a function 
> I currently am sniffing ;-)
> 
>     echo "p:kprobe_tpacket_rcv tpacket_rcv+26 skb=%di:x64" >> kprobe_events
>     (gdb) disass tcpaket_rcv
>     Dump of assembler code for function tpacket_rcv:
>       0xffffffffb9d79e10 <+0>:     endbr64
>       ...
>       0xffffffffb9d79e2a <+26>:    jmp    0xffffffffc1389000 <kprobe_optinsn_page>
> 
> Of course the latter only serves my curiosity; but it shows I'm looking at the 
> "live" code. It matters in other cases of dynamic code, like static branches.

Yep.

> 
> So, is there currently another method to reach the same effect ?

Besides kgdb (usually another machine connected to the live kernel),
this is probably the only way to do what you want.

-- Steve