深入探究Linux Kprobe机制

一时失言乱红尘 2022-10-24 01:48 338阅读 0赞

![format_png][]

# 概述 #

kprobe机制用于在内核中动态添加一些探测点，可以满足一些调试需求。本文主要探寻kprobe的执行路径，也就是说如何trap到kprobe，以及如何回到原路径继续执行。

# 实例 #

先通过一个实例来感受下kprobe，linux中有一个现成的实例：samples/kprobes/kprobe\_example.c 由于当前验证环境是基于qemu+arm64，我删除了其他架构的代码，并稍稍做了一下改动：

#include <linux/kernel.h>
    #include <linux/module.h>
    #include <linux/kprobes.h>
    
    #define MAX_SYMBOL_LEN  64
    static char symbol[MAX_SYMBOL_LEN] = "_do_fork";
    module_param_string(symbol, symbol, sizeof(symbol), 0644);
    
    /* For each probe you need to allocate a kprobe structure */
    static struct kprobe kp = {
      .symbol_name  = symbol,
    };
    
    /* kprobe pre_handler: called just before the probed instruction is executed */
    static int handler_pre(struct kprobe *p, struct pt_regs *regs)
    {
      pr_info("<%s> pre_handler: p->addr = 0x%p, pc = 0x%lx,"
          " pstate = 0x%lx\n",
        p->symbol_name, p->addr, (long)regs->pc, (long)regs->pstate);
    
      dump_stack();
      /* A dump_stack() here will give a stack backtrace */
      return 0;
    }
    
    /* kprobe post_handler: called after the probed instruction is executed */
    static void handler_post(struct kprobe *p, struct pt_regs *regs,
            unsigned long flags)
    {
      pr_info("<%s> post_handler: p->addr = 0x%p, pstate = 0x%lx\n",
        p->symbol_name, p->addr, (long)regs->pstate);
      dump_stack();
    }
    
    /*
     * fault_handler: this is called if an exception is generated for any
     * instruction within the pre- or post-handler, or when Kprobes
     * single-steps the probed instruction.
     */
    static int handler_fault(struct kprobe *p, struct pt_regs *regs, int trapnr)
    {
      pr_info("fault_handler: p->addr = 0x%p, trap #%dn", p->addr, trapnr);
      /* Return 0 because we don't handle the fault. */
      return 0;
    }
    
    static int __init kprobe_init(void)
    {
      int ret;
      kp.pre_handler = handler_pre;
      kp.post_handler = handler_post;
      kp.fault_handler = handler_fault;
    
      ret = register_kprobe(&kp);
      if (ret < 0) {
        pr_err("register_kprobe failed, returned %d\n", ret);
        return ret;
      }
      pr_info("Planted kprobe at %p\n", kp.addr);
      return 0;
    }
    
    static void __exit kprobe_exit(void)
    {
      unregister_kprobe(&kp);
      pr_info("kprobe at %p unregistered\n", kp.addr);
    }
    
    module_init(kprobe_init)
    module_exit(kprobe_exit)
    MODULE_LICENSE("GPL");

这段代码很简单，默认情况下，kprobe做了3个钩子，分别在\_do\_fork对应位置的指令执行之前，执行之后，以及出异常的时候。插入该内核模块之后，随便输入一条命令，可看到下面的打印：

[   19.882832] kprobe_example: loading out-of-tree module taints kernel.
    [   19.900442] Planted kprobe at (____ptrval____)
    [   19.908571] <_do_fork> pre_handler: p->addr = 0x(____ptrval____), pc = 0xffff0000080d2c98, pstate = 0x80000005
    [   19.913657] CPU: 0 PID: 1358 Comm: udevd Tainted: G           O      4.18.0 #7
    [   19.916239] Hardware name: linux,dummy-virt (DT)
    [   19.918400] Call trace:
    [   19.919373]  dump_backtrace+0x0/0x180
    [   19.920681]  show_stack+0x14/0x20
    [   19.921817]  dump_stack+0x90/0xb4
    [   19.923678]  handler_pre+0x24/0x68 [kprobe_example]
    [   19.926357]  kprobe_breakpoint_handler+0xbc/0x160
    [   19.926627]  brk_handler+0x70/0x88
    [   19.926802]  do_debug_exception+0x94/0x160
    [   19.927102]  el1_dbg+0x18/0x78
    [   19.927299]  _do_fork+0x0/0x358
    [   19.927465]  el0_svc_naked+0x30/0x34
    [   19.928973] <_do_fork> post_handler: p->addr = 0x(____ptrval____), pstate = 0x80000005
    [   19.929361] CPU: 0 PID: 1358 Comm: udevd Tainted: G           O      4.18.0 #7
    [   19.929693] Hardware name: linux,dummy-virt (DT)
    [   19.929962] Call trace:
    [   19.930102]  dump_backtrace+0x0/0x180
    [   19.930289]  show_stack+0x14/0x20
    [   19.930461]  dump_stack+0x90/0xb4
    [   19.934684]  handler_post+0x24/0x30 [kprobe_example]
    [   19.934968]  post_kprobe_handler+0x54/0x98
    [   19.935234]  kprobe_single_step_handler+0x74/0xa8
    [   19.935389]  single_step_handler+0x3c/0xb0
    [   19.935516]  do_debug_exception+0x94/0x160
    [   19.935642]  el1_dbg+0x18/0x78
    [   19.935965]  0xffff000000ac8004
    [   19.936067]  el0_svc_naked+0x30/0x34

probe和post钩子得到执行，这对查看内核的调用栈非常有帮助。

# 深入探究 #

**是否只能基于symbol\_name做kprobe？**

显然不太可能，struct kprobe中有一个addr成员，很明显是可以直接基于地址做kprobe的。把这段代码：

#define MAX_SYMBOL_LEN  64
    static char symbol[MAX_SYMBOL_LEN] = "_do_fork";
    module_param_string(symbol, symbol, sizeof(symbol), 0644);
    
    /* For each probe you need to allocate a kprobe structure */
    static struct kprobe kp = {
      .symbol_name  = symbol,
    };

修改为：

/* For each probe you need to allocate a kprobe structure */
    static struct kprobe kp = {
      .addr= (kprobe_opcode_t *)0xffff0000080d2c98,
    };

效果是一样的。

**kprobe是如何动态添加探针的？**

这个肯定要分析代码了，好在代码相当简单：

register_kprobe
       |------arm_kprobe
       |   |------__arm_kprobe
       |   |   |------arch_arm_kprobe
    
    /* arm kprobe: install breakpoint in text */
    void __kprobes arch_arm_kprobe(struct kprobe *p)
    {
      patch_text(p->addr, BRK64_OPCODE_KPROBES);
    }

从注释就可以很明显看出来，是把addr对应位置的指令修改为brk指令，当然这里说的是ARM64架构。那么一旦CPU执行到addr，就会触发异常，trap到kprobe注册的钩子上。

**post钩子为什么会用到single step？**

从上面的调用栈可以看到，post钩子实际上是通过单步断点trap过来的？为什么需要用到单步断点呢？这个其实很好解释。我们先来理一下kprobe的过程：

*  把addr位置的指令修改为brk指令
 *  CPU执行到addr处trap到pre执行
 *  pre执行完毕后需要把addr处的指令恢复
 *  CPU继续执行addr处的指令
 *  CPU执行post

那么CPU如何才能执行到post，很简单，使能单步执行就可以了。肯定有人会说，可以把addr+4的指令也替换成brk，这个肯定是不行的，因为ARM64可能是32位/16位指令混编的，即便是固定32位指令，CPU下一条要执行的指令也不一定是addr+4，比如当前addr是一条跳转指令。

**fault\_handler 钩子什么时候会用到？**

通过分析代码可知，当发生page fault的时候，会调用当前正在running的kprobe的fault\_handler钩子，所以这里发生page fault的代码并不一定是addr处的指令，也可能是pre或者post中的指令。我在pre中注入一段访问0地址的逻辑：

static void * g_addr=0;
    static int handler_pre(struct kprobe *p, struct pt_regs *regs) __attribute__((optimize("O0")));
    static int handler_pre(struct kprobe *p, struct pt_regs *regs)
    {
      pr_info("<%s> pre_handler: p->addr = 0x%p, pc = 0x%lx,"
          " pstate = 0x%lx\n",
        p->symbol_name, p->addr, (long)regs->pc, (long)regs->pstate);
    
        printk("%d\n", *(char *)g_addr);
      /* A dump_stack() here will give a stack backtrace */
      return 0;
    }

经验证确实调用到了fault\_handler钩子：

[   17.272594] kprobe_example: loading out-of-tree module taints kernel.
    [   17.294266] Planted kprobe at (____ptrval____)
    # 
    # ls
    [   19.072586] <(null)> pre_handler: p->addr = 0x(____ptrval____), pc = 0xffff0000080d2c98, pstate = 0x80000005
    [   19.073189] fault_handler: p->addr = 0x(____ptrval____), trap #-1778384890n
    [   19.073568] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
    [   19.074271] Mem abort info:
    [   19.074393]   ESR = 0x96000006
    [   19.074641]   Exception class = DABT (current EL), IL = 32 bits
    [   19.074887]   SET = 0, FnV = 0
    [   19.075014]   EA = 0, S1PTW = 0
    [   19.075174] Data abort info:
    [   19.075324]   ISV = 0, ISS = 0x00000006
    [   19.075455]   CM = 0, WnR = 0
    [   19.075774] user pgtable: 4k pages, 48-bit VAs, pgdp = (____ptrval____)
    [   19.076005] [0000000000000000] pgd=00000000485c6003, pud=00000000bb2f4003, pmd=0000000000000000
    [   19.076596] Internal error: Oops: 96000006 [#1] PREEMPT SMP
    [   19.076924] Modules linked in: kprobe_example(O)
    [   19.077693] CPU: 0 PID: 1387 Comm: sh Tainted: G           O      4.18.0 #7
    [   19.077927] Hardware name: linux,dummy-virt (DT)
    [   19.078298] pstate: 400003c5 (nZcv DAIF -PAN -UAO)
    [   19.078962] pc : handler_pre+0x50/0x70 [kprobe_example]
    [   19.079149] lr : handler_pre+0x44/0x70 [kprobe_example]
    [   19.079359] sp : ffff00000ac63c00
    [   19.079565] x29: ffff00000ac63c00 x28: ffff80007a3c9a80 
    [   19.079821] x27: ffff000008ac1000 x26: 00000000000000dc 
    [   19.080047] x25: ffff80007dfb7788 x24: 0000000000000000 
    [   19.080363] x23: ffff0000080d2c98 x22: ffff00000ac63d70 
    [   19.080621] x21: ffff000000ac2000 x20: 0000800074f02000 
    [   19.080863] x19: ffff0000090b5788 x18: ffffffffffffffff 
    [   19.081197] x17: 0000000000000000 x16: 0000000000000000 
    [   19.081501] x15: ffff0000090d96c8 x14: 3030303030666666 
    [   19.081720] x13: 667830203d206370 x12: ffff0000090d9940 
    [   19.081933] x11: ffff0000085dd8d8 x10: 5f287830203d2072 
    [   19.082189] x9 : 0000000000000017 x8 : 2065746174737020 
    [   19.082455] x7 : 2c38396332643038 x6 : ffff80007dfb8240 
    [   19.082660] x5 : ffff80007dfb8240 x4 : 0000000000000000 
    [   19.082871] x3 : ffff80007dfbf030 x2 : 793b575e486def00 
    [   19.083068] x1 : 0000000000000000 x0 : 0000000000000000 
    [   19.083390] Process sh (pid: 1387, stack limit = 0x(____ptrval____))
    [   19.083783] Call trace:
    [   19.084020]  handler_pre+0x50/0x70 [kprobe_example]
    [   19.084470]  kprobe_breakpoint_handler+0xbc/0x160
    [   19.084693]  brk_handler+0x70/0x88
    [   19.084839]  do_debug_exception+0x94/0x160
    [   19.085132]  el1_dbg+0x18/0x78
    [   19.085259]  _do_fork+0x0/0x358
    [   19.085443]  el0_svc_naked+0x30/0x34
    [   19.085939] Code: 95d9a53f b0000000 9101c000 f9400000 (39400000) 
    [   19.086713] ---[ end trace 3bb11c402bc37363 ]---

但由于fault\_handler中没有对该异常做处理，所以依然挂死了。fault\_handler可以用于报错或者纠错，报错可以自定义一些错误信息给用户，以便分析错误；纠错用于修改错误，那么针对当前这个错误应该怎么做纠错呢？在fault\_handler中为g\_addr分配空间？，这显然不行，g\_addr肯定已经被载入寄存器了，此时修改已经太迟。唯一的方法就是修改寄存器的值，而寄存器此时肯定已经入栈了，所以必须修改寄存器在栈里面的内容。下面我们来fixup这个挂死问题：

*  根据挂死信息

[   19.084020]  handler_pre+0x50/0x70 [kprobe_example]

是在handler\_pre+0x50这个位置出异常的，通过反汇编得知这个位置对应的指令是：

50:   39400000        ldrb    w0, [x0]

x0的内容是0，所以这里是读0地址，很明显，g\_addr被载入到了x0中，所以只要修改x0就可以了。

*  fixup实现

修改fault\_handler函数：

static int g_addr1=0x5a;
    static int handler_fault(struct kprobe *p, struct pt_regs *regs, int trapnr)
    {
      pr_info("fault_handler: p->addr = 0x%p, trap #%dn", p->addr, trapnr);
      regs->regs[0] = (unsigned long)&g_addr1;
      /* Return 0 because we don't handle the fault. */
      return 1;
    }

*  验证

[   58.882059] <(null)> pre_handler: p->addr = 0x(____ptrval____), pc = 0xffff0000080d2c98, pstate = 0x80000005
    [   58.882393] fault_handler: p->addr = 0x(____ptrval____), trap #-1778384890n
    [   58.882411] 90
    [   58.882658] <(null)> post_handler: p->addr = 0x(____ptrval____), pstate = 0x80000005
    [   58.882960] CPU: 1 PID: 1388 Comm: sh Tainted: G           O      4.18.0 #7

fault\_handler之后，pre\_handler打印了g\_addr对应地址的内容是90，也就是0x5a。大功告成，我们成功的让内核访问了0地址，并且返回了0x5a。

来自：liuhangtiant

链接：https://blog.csdn.net/liuhangtiant/article/details/109555795

![虚线阴影分割线][format_png 1]

![format_png 2][]

5T技术资源大放送！包括但不限于：C/C++，Arm, Linux，Android，人工智能，单片机，树莓派，等等。在公众号内回复「peter」，即可免费获取！！

![format_png 3][] **记得点击****分享****、****赞****和****在看****，给我充点儿电吧**

[format_png]: /images/20221024/aeaaddc610af40e983467044d9b9bd54.png
[format_png 1]: /images/20221024/a41e070697ad45f08a25df80e3a821e4.png
[format_png 2]: /images/20221024/151043862044416e89e3812946a3b6a2.png
[format_png 3]: /images/20221024/a36e5c766b3641a2abf67bb6f30fbfc0.png