内核调测工具Kprobe之原理篇

本文转载自微信公众号「人人都是极客」，作者布道师Peter。转载本文请联系人人都是极客公众号。

创新互联IDC提供业务:服务器主机托管,成都服务器租用,服务器主机托管,重庆服务器租用等四川省内主机托管与主机租用业务;数据中心含:双线机房,BGP机房,电信机房,移动机房,联通机房。

上篇文章我们讲了Kprobe的用法，这次我们一起看下其实现的原理。

在上次的模块例子中插入dump_stack函数，获得调用栈的情况，根据栈来反推其调用流程：

 
 
 
 
  
  
  
  Call trace: 
  
  
  
  [] dump_backtrace+0x0/0x268 
  
  
  
  [] show_stack+0x20/0x28 
  
  
  
  [] dump_stack+0xb4/0xf0 
  
  
  
  [] handler_pre+0x38/0x50 [kprobe_example] 
  
  
  
  [] kprobe_breakpoint_handler+0x160/0x1d4 
  
  
  
  [] brk_handler+0x7c/0x90 
  
  
  
  [] do_debug_exception+0xa0/0x174 
  
  
  
  Exception stack(0xffff000012f7bd40 to 0xffff000012f7be80) 
  
  
  
  bd40: 0000000001200011 0000000000000000 0000000000000000 0000000000000000 
  
  
  
  bd60: 0000f39a6ce05558 0000000000000000 0000f39a6ce05558 0000000000000073 
  
  
  
  bd80: 00000000000000dc 0000000000000000 0000000000000000 0000000000000000 
  
  
  
  bda0: 0000f39a6ce05558 0000000000000000 00000000ffffffff 0000fffffa1150d8 
  
  
  
  bdc0: ffff0000080e1b40 0000f39a6c99fd10 0000000000000008 0000000000000000 
  
  
  
  bde0: 0000000001200011 00000000ffffffff 0000f39a6c99fd30 0000000040000000 
  
  
  
  be00: 0000000000000015 0000000000000124 00000000000000dc ffff000009122000 
  
  
  
  be20: ffff8008f0385700 ffff000012f7be80 ffff0000080e1b84 ffff000012f7be80 
  
  
  
  be40: ffff0000080e1620 0000000080000145 00000000ffffffff 6544f7a9c1a3c100 
  
  
  
  be60: 0000ffffffffffff ffff000008083ac0 ffff000012f7be80 ffff0000080e1620 
  
  
  
  [] el1_dbg+0x18/0x74 
  
  
  
  [] _do_fork+0x0/0x414

可以看出流程为：el1_dbg->do_debug_exception->brk_handler->kprobe_breakpoint_handler->kprobe_handler->handler_pre

从上图可以看出当中断触发时进入el1_sync，然后读取esr_el1寄存器的值，并判断异常的具体类型 ESR_ELx_EC_BREAKPT_CUR=0x31，即EC=110001，进入el1_dbg函数。根据EC=11000的类型我们知道触发当前中断的是breakpoint exception，如下所示：

那么问题来了，breakpoint指令是如何触发的?搞清楚了这个问题也就理解了kprobe添加探针的本质。

替换breakpoint指令

先来看下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指令,一旦cpu执行到addr，就会触发brk。从而进入上面说的中断函数el1_sync，紧接着进入 kprobe_handler.

 
 
 
 
  
  
  
  static void __kprobes kprobe_handler(struct pt_regs *regs) 
  
  
  
  { 
  
  
  
   struct kprobe *p, *cur_kprobe; 
  
  
  
   struct kprobe_ctlblk *kcb; 
  
  
  
   unsigned long addr = instruction_pointer(regs); 
  
  
  
   
  
  
  
   kcb = get_kprobe_ctlblk(); 
  
  
  
   cur_kprobe = kprobe_running(); 
  
  
  
   
  
  
  
   p = get_kprobe((kprobe_opcode_t *) addr); //根据pc值获取kprobe 
  
  
  
   
  
  
  
   if (p) { 
  
  
  
    if (cur_kprobe) { 
  
  
  
     if (reenter_kprobe(p, regs, kcb)) 
  
  
  
      return; 
  
  
  
    } else { 
  
  
  
     /* Probe hit */ 
  
  
  
     set_current_kprobe(p); 
  
  
  
     kcb->kprobe_status = KPROBE_HIT_ACTIVE;//开始处理kprobe 
  
  
  
   
  
  
  
     if (!p->pre_handler || !p->pre_handler(p, regs)) { 
  
  
  
      setup_singlestep(p, regs, kcb, 0);  
  
  
  
      return; 
  
  
  
     } 
  
  
  
    } 
  
  
  
  ...... 
  
  
  
  }

可以看出kprobe_handler里先是进入pre_handler，然后通过setup_singlestep设置single-step相关寄存器，为下一步执行原指令时发生single-step异常做准备。

进入single-step

经过上面的步骤，pre_handler得到了执行，从异常态返回后，原指令也得到了执行，但是由于设置了single-step模式，所以执行完原指令后，马上又进入了single-step的exception。流程为：el1_dbg->do_debug_exception->single_step_handler->kprobe_single_step_handler->post_kprobe_handler->post_handler

总结

至此，我们知道Kprobe实现的本质是breakpoint和single-step的结合，这一点和大多数调试工具一样，比如kgdb/gdb。上面我们是从trace信息反推出来的执行流程，现在我们在从正面整理一下整个过程的来龙去脉：

注册kprobe。注册的每个kprobe对应一个kprobe结构体，该结构体记录着插入点(位置)，以及该插入点本来对应的指令original_opcode;
替换原有指令。使能kprobe的时候，将插入点位置的指令替换为一条异常(BRK)指令，这样当CPU执行到插入点位置时会陷入到异常态;
执行pre_handler。进入异常态后，首先执行pre_handler，然后利用CPU提供的单步调试(single-step)功能，设置好相应的寄存器，将下一条指令设置为插入点处本来的指令，从异常态返回;
再次陷入异常态。上一步骤中设置了single-step相关的寄存器，所以original_opcode刚一执行，便会再次陷入异常态，此时将signle-step清除，并且执行post_handler，然后从异常态安全返回。

步骤2，3，4便是一次kprobe工作的过程，它的一个基本思路就是将本来执行一条指令扩展成执行kprobe->pre_handler--->原指令--->kprobe-->post_handler这样三个过程。

由于考虑到放太多代码不利于阅读，本文并没有详细解读代码对上面流程的实现，感兴趣的小伙伴可以自行阅读，遇到问题可以留言或者群里讨论，最后整理下代码中涉及到的相关寄存器。

相关寄存器

PSTATE

PSTATE不是一个寄存器，它表示的是保存当前process状态信息的一组寄存器或者一些标志位信息的统称。

 
 
 
 
  
  
  
  负数标志 Negative condition flag 
  
  
  
  零数标志 Zero condition flag 
  
  
  
  进位标志 Carry condition flag 
  
  
  
  溢出标志 Overflow condition flag 
  
  
  
  D : debug exception MASK ：Watchpoint, Breakpoint, and Software Step exceptions 
  
  
  
  A : SError interrupt MASK 
  
  
  
  I ：IRQ interrupt MASK 
  
  
  
  F ：FIQ  interrupt MASK 
  
  
  
  EL, bits [3:2] 
  
  
  
  00 EL0 
  
  
  
  01 EL1 
  
  
  
  10 EL2 
  
  
  
  11 EL3 
  
  
  
  SP, bit [0] 
  
  
  
  0 Use SP_EL0 at all Exception levels. 
  
  
  
  1 Use SP_ELx for Exception level ELx. 
  
  
  
  PAN, bit [22] 特权访问进制 
  
  
  
  0 Privileged reads and write are not disabled by this mechanism. 
  
  
  
  1 Disables privileged read and write accesses to addresses accessible at EL0 for an enabled stage 1 translation regime that defines the EL0 permissions

SPSR

当异常发生的时候，保存当前的PSTATE(CPSR)的状态。

PSTATE.{N, Z, C, V}：条件标志位，这些位的含义跟之前AArch32位一样，分别表示补码标志，运算结果为0标志，进位标志，带符号位溢出标志.
PSTATE.SS：异常发生的时候，通过设置 MDSCR_EL1.SS 为 1 启动单步调试机制.
PSTATE.IL：异常执行状态标志，非法异常产生的时候，会设置这个标志位，会导致的事件.
PSTATE.{D, A, I, F}：D表示debug异常产生，比如软件断点指令/断点/观察点/向量捕获/软件单步等;A, I, F表示异步异常标志，异步异常会有两种类型：一种是物理中断产生的，包括SError(系统错误类型，包括外部数据终止)，IRQ或者FIQ;另一种是虚拟中断产生的，这种中断发生在运行在EL2管理者enable的情况下：vSError，vIRQ，vFIQ;

MDSCR_EL1

Monitor Debug System Control Register

分享文章：内核调测工具Kprobe之原理篇
网站URL：http://www.cdxtjz.cn/article/dpppgep.html

内核调测工具Kprobe之原理篇

其他资讯