[[382495]]

本文轉(zhuǎn)載自微信公眾號(hào)「人人都是極客」，作者布道師Peter。轉(zhuǎn)載本文請(qǐng)聯(lián)系人人都是極客公眾號(hào)。  

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

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

Call trace: 
[<ffff00000808bd84>] dump_backtrace+0x0/0x268 
[<ffff00000808c00c>] show_stack+0x20/0x28 
[<ffff0000090e63e0>] dump_stack+0xb4/0xf0 
[<ffff00000168d0c8>] handler_pre+0x38/0x50 [kprobe_example] 
[<ffff000009103a14>] kprobe_breakpoint_handler+0x160/0x1d4 
[<ffff000008084fd0>] brk_handler+0x7c/0x90 
[<ffff000008081354>] 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 
[<ffff0000080830f0>] el1_dbg+0x18/0x74 
[<ffff0000080e1620>] _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è)過程的來龍去脈：

1. 注冊(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;
2. 替換原有指令。使能kprobe的時(shí)候，將插入點(diǎn)位置的指令替換為一條異常(BRK)指令，這樣當(dāng)CPU執(zhí)行到插入點(diǎn)位置時(shí)會(huì)陷入到異常態(tài);
3. 執(zhí)行pre_handler。進(jìn)入異常態(tài)后，首先執(zhí)行pre_handler，然后利用CPU提供的單步調(diào)試(single-step)功能，設(shè)置好相應(yīng)的寄存器，將下一條指令設(shè)置為插入點(diǎn)處本來的指令，從異常態(tài)返回;
4. 再次陷入異常態(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)寄存器。

相關(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;

MDSCR_EL1

Monitor Debug System Control Register