上篇文章我們講了Kprobe的用法，這次我們一起看下其實(shí)現(xiàn)的原理。

在上次的模塊例子中插入dump_stack函數(shù)，獲得調(diào)用棧的情況，根據(jù)棧來反推其調(diào)用流程：

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

從上圖可以看出當(dāng)中斷觸發(fā)時(shí)進(jìn)入el1_sync，然后讀取esr_el1寄存器的值，并判斷異常的具體類型 ESR_ELx_EC_BREAKPT_CUR=0x31，即EC=110001，進(jìn)入el1_dbg函數(shù)。根據(jù)EC=11000的類型我們知道觸發(fā)當(dāng)前中斷的是breakpoint exception，如下所示：

那么問題來了，breakpoint指令是如何觸發(fā)的？搞清楚了這個(gè)問題也就理解了kprobe添加探針的本質(zhì)。

替換breakpoint指令

先來看下kprobe的注冊(cè)流程：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); 
}

可以清晰看出這里把a(bǔ)ddr對(duì)應(yīng)位置的指令修改為brk指令,一旦cpu執(zhí)行到addr，就會(huì)觸發(fā)brk。從而進(jìn)入上面說的中斷函數(shù)el1_sync，緊接著進(jìn)入 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); //根據(jù)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里先是進(jìn)入pre_handler，然后通過setup_singlestep設(shè)置single-step相關(guān)寄存器，為下一步執(zhí)行原指令時(shí)發(fā)生single-step異常做準(zhǔn)備。

進(jìn)入single-step

經(jīng)過上面的步驟，pre_handler得到了執(zhí)行，從異常態(tài)返回后，原指令也得到了執(zhí)行，但是由于設(shè)置了single-step模式，所以執(zhí)行完原指令后，馬上又進(jìn)入了single-step的exception。流程為：el1_dbg->do_debug_exception->single_step_handler->kprobe_single_step_handler->post_kprobe_handler->post_handler

總結(jié)

至此，我們知道Kprobe實(shí)現(xiàn)的本質(zhì)是breakpoint和single-step的結(jié)合，這一點(diǎn)和大多數(shù)調(diào)試工具一樣，比如kgdb/gdb。上面我們是從trace信息反推出來的執(zhí)行流程，現(xiàn)在我們?cè)趶恼嬲硪幌抡麄€(gè)過程的來龍去脈：

注冊(cè)kprobe。注冊(cè)的每個(gè)kprobe對(duì)應(yīng)一個(gè)kprobe結(jié)構(gòu)體，該結(jié)構(gòu)體記錄著插入點(diǎn)（位置），以及該插入點(diǎn)本來對(duì)應(yīng)的指令original_opcode；

替換原有指令。使能kprobe的時(shí)候，將插入點(diǎn)位置的指令替換為一條異常（BRK）指令，這樣當(dāng)CPU執(zhí)行到插入點(diǎn)位置時(shí)會(huì)陷入到異常態(tài)；

執(zhí)行pre_handler。進(jìn)入異常態(tài)后，首先執(zhí)行pre_handler，然后利用CPU提供的單步調(diào)試（single-step）功能，設(shè)置好相應(yīng)的寄存器，將下一條指令設(shè)置為插入點(diǎn)處本來的指令，從異常態(tài)返回；

再次陷入異常態(tài)。上一步驟中設(shè)置了single-step相關(guān)的寄存器，所以original_opcode剛一執(zhí)行，便會(huì)再次陷入異常態(tài)，此時(shí)將signle-step清除，并且執(zhí)行post_handler，然后從異常態(tài)安全返回。

步驟2，3，4便是一次kprobe工作的過程，它的一個(gè)基本思路就是將本來執(zhí)行一條指令擴(kuò)展成執(zhí)行kprobe->pre_handler--->原指令--->kprobe-->post_handler這樣三個(gè)過程。

由于考慮到放太多代碼不利于閱讀，本文并沒有詳細(xì)解讀代碼對(duì)上面流程的實(shí)現(xiàn)，感興趣的小伙伴可以自行閱讀，遇到問題可以留言或者群里討論，最后整理下代碼中涉及到的相關(guān)寄存器。

PSTATE

PSTATE不是一個(gè)寄存器，它表示的是保存當(dāng)前process狀態(tài)信息的一組寄存器或者一些標(biāo)志位信息的統(tǒng)稱。

負(fù)數(shù)標(biāo)志 Negative condition flag

零數(shù)標(biāo)志 Zero condition flag

進(jìn)位標(biāo)志 Carry condition flag

溢出標(biāo)志 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] 特權(quán)訪問進(jìn)制
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

當(dāng)異常發(fā)生的時(shí)候，保存當(dāng)前的PSTATE(CPSR)的狀態(tài)。

PSTATE.{N, Z, C, V}：條件標(biāo)志位，這些位的含義跟之前AArch32位一樣，分別表示補(bǔ)碼標(biāo)志，運(yùn)算結(jié)果為0標(biāo)志，進(jìn)位標(biāo)志，帶符號(hào)位溢出標(biāo)志.PSTATE.SS：異常發(fā)生的時(shí)候，通過設(shè)置 MDSCR_EL1.SS 為 1 啟動(dòng)單步調(diào)試機(jī)制.PSTATE.IL：異常執(zhí)行狀態(tài)標(biāo)志，非法異常產(chǎn)生的時(shí)候，會(huì)設(shè)置這個(gè)標(biāo)志位，會(huì)導(dǎo)致的事件.PSTATE.{D, A, I, F}：D表示debug異常產(chǎn)生，比如軟件斷點(diǎn)指令/斷點(diǎn)/觀察點(diǎn)/向量捕獲/軟件單步等；A, I, F表示異步異常標(biāo)志，異步異常會(huì)有兩種類型：一種是物理中斷產(chǎn)生的，包括SError（系統(tǒng)錯(cuò)誤類型，包括外部數(shù)據(jù)終止），IRQ或者FIQ；另一種是虛擬中斷產(chǎn)生的，這種中斷發(fā)生在運(yùn)行在EL2管理者enable的情況下：vSError，vIRQ，vFIQ；