linux kernel tracing

It`s hard to believe but linux kernel has almost exact copy of windows ETW - event tracing. It is just as difficult to make it work, it is poorly documented, very complex and fragile. And yes, as you can guess - it also can`t show who and which parts of it in use. So I wrote some code to dump registered funcs in tracepoints and to check file ops for files in /sys/kernel/tracing/events

Lets start with tracepoints. As you see this structure has strange looked list of functions in field funcs, and calling happens in functions like event_triggers_call. How we can find this tracepoints? Well,  they stored in trace_event_call->tp and array of pointers to trace_event_call located between symbols __start_ftrace_events & __stop_ftrace_events. Unfortunately all this treasures located in discardable section .init.data. But because they were all declared in the same manner we can find them by name - all symbols with prefix __tracepoint_ is what we need. So some examples (you can run lkmem -c -t vmlinux system.map to get this):

 __tracepoint_sys_enter at 0xffffffff8b82e340: enabled 0 cnt 0
  regfunc 0xffffffff8a192330 - kernel!syscall_regfunc
  unregfunc 0xffffffff8a1923f0 - kernel!syscall_unregfunc

Well, no clients right now - cnt 0

Next about /sys/kernel/tracing/events files (this is perverted inhuman interface to manage trace events). I just dumping file->f_path.dentry->d_inode->i_fop for each such file. Sample of output (you can achieve this with lkmem -s vmlinux system.map path_to_some_sys_kernel_tracing_file):

arm64 disasm for linux kernel

I added today disassembler for arm64 linux kernel to search pointers. It turned out to be surprisingly difficult to do for several reasons (disasm for x64 is only 383 LOC vs 618 for arm64)

One of them is poor code produced by some gcc versions

But the main problem is arm64 opcodes. Lets see simple indirect call:

  ADRP            X27, #mh_filter@PAGE

  CMP             W22, #0x3A ; ':'

  B.EQ            loc_FFFFFFC010CC7140

  CMP             W22, #0x87

  B.NE            loc_FFFFFFC010CC7188

  LDR             X2, [X27,#mh_filter@PAGEOFF]

  CBZ             X2, loc_FFFFFFC010CC7188

  MOV             X1, skb

  MOV             X0, X28

  BLR             X2

    

compare this with code to call list of funcs from tracepoints:

  ADRP            __data, #__tracepoint_cpu_idle@PAGE

  ADD             X0, X0, #__tracepoint_cpu_idle@PAGEOFF

  MOV             X29, SP

  STR             X19, [SP,#var_s10]

  LDR             X19, [X0,#(__tracepoint_powernv_throttle.funcs - 0xFFFFFFC011A562C0)]

 ...

loc_FFFFFFC01011FC60:

  LDR             X4, [X19]

  MOV             W3, W20

  LDR             X0, [X19,#8]

  MOV             X2, X21

  MOV             W1, W22

  BLR             X4

  LDR             X0, [X19,#0x18]!

  CBNZ            X0, loc_FFFFFFC01011FC60

In second case register X4 was loaded from X19, which in turn was loaded from some memory, so I need to track how many times content of register was loaded

Anyway results is +34 newly discovered functions pointers

functions pointers in linux kernel data sections

I wrote simple program to estimate size of problem. Yes, I know about CFI but it seems that even on kernel 5.11 on fresh Ubuntu this mechanism is not implemented and indirect calls looks like:

  mov     rax, cs:XXX

  call    __x86_indirect_thunk_rax

__x86_indirect_thunk_rax proc near: 

  jmp     rax

First approach is just to scan .data section - you can do this running

./lkmem path-to-unpacked-kernel path-to-System.map

Some results:

• arm64 5.11.0: 9893
• x64 5.8-53: 10698
• x64 5.11.0: 13414
• x64 4.18: 16224

Ok, how about not yet inited pointers (or pointers in .bss section)? We need use disassembler - just disasm all functions in .text and find indirect calls and calls to __x86_indirect_thunk_XXX. Results (with -d option):

• x64 4.18: +42
• x64 5.8-53: +52
• x64 5.11.0: +45

and with .bss section (option -b):

• x64 4.18: +99
• x64 5.8-53: +120
• x64 5.11.0: +109

dumper of linux kernel notification chains

There seems to be one little-known thing in linux kernel - notification chains. So they have literal analogue of PsSetLoadImageNotifyRoutine - function register_module_notifier. And similarly they don't have a function to enumerate registered notifications - I don`t know why. Maybe they were bitten by Microsoft. Or maybe I want too much from people whose even "The Linux Kernel Module Programming Guide" contains an error in the code example. Anyway I decided to write my own (btw the last time I wrote drivers for Linux was something around 20 years ago)

How to run

git clone https://github.com/redplait/lkcd.git

cd lkcd

make

sudo insmod ./lkcd.ko

cd test

make

sudo ./dtest

Sample of output (from fresh Ubuntu):