內(nèi)核調(diào)測(cè)工具Kprobe之原理篇
本文轉(zhuǎn)載自微信公眾號(hào)「人人都是極客」，作者布道師Peter。轉(zhuǎn)載本文請(qǐng)聯(lián)系人人都是極客公眾號(hào)。
上篇文章我們講了Kprobe的用法，這次我們一起看下其實(shí)現(xiàn)的原理。
在上次的模塊例子中插入dump_stack函數(shù)，獲得調(diào)用棧的情況，根據(jù)棧來(lái)反推其調(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寄存器的值，并判斷異常的具體類(lèi)型 ESR_ELx_EC_BREAKPT_CUR=0x31，即EC=110001，進(jìn)入el1_dbg函數(shù)。根據(jù)EC=11000的類(lèi)型我們知道觸發(fā)當(dāng)前中斷的是breakpoint exception，如下所示：
那么問(wèn)題來(lái)了，breakpoint指令是如何觸發(fā)的?搞清楚了這個(gè)問(wèn)題也就理解了kprobe添加探針的本質(zhì)。
替換breakpoint指令
先來(lái)看下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)入上面說(shuō)的中斷函數(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;//開(kāi)始處理kprobe
- if (!p->pre_handler || !p->pre_handler(p, regs)) {
- setup_singlestep(p, regs, kcb, 0);
- return;
- }
- }
- ......
- }
可以看出kprobe_handler里先是進(jìn)入pre_handler，然后通過(guò)setup_singlestep設(shè)置single-step相關(guān)寄存器，為下一步執(zhí)行原指令時(shí)發(fā)生single-step異常做準(zhǔn)備。
進(jìn)入single-step
經(jīng)過(guò)上面的步驟，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信息反推出來(lái)的執(zhí)行流程，現(xiàn)在我們?cè)趶恼嬲硪幌抡麄€(gè)過(guò)程的來(lái)龍去脈：
- 注冊(cè)kprobe。注冊(cè)的每個(gè)kprobe對(duì)應(yīng)一個(gè)kprobe結(jié)構(gòu)體，該結(jié)構(gòu)體記錄著插入點(diǎn)(位置)，以及該插入點(diǎn)本來(lái)對(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)處本來(lái)的指令，從異常態(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工作的過(guò)程，它的一個(gè)基本思路就是將本來(lái)執(zhí)行一條指令擴(kuò)展成執(zhí)行kprobe->pre_handler--->原指令--->kprobe-->post_handler這樣三個(gè)過(guò)程。
由于考慮到放太多代碼不利于閱讀，本文并沒(méi)有詳細(xì)解讀代碼對(duì)上面流程的實(shí)現(xiàn)，感興趣的小伙伴可以自行閱讀，遇到問(wèn)題可以留言或者群里討論，最后整理下代碼中涉及到的相關(guān)寄存器。
相關(guān)寄存器
PSTATE
PSTATE不是一個(gè)寄存器，它表示的是保存當(dāng)前process狀態(tài)信息的一組寄存器或者一些標(biāo)志位信息的統(tǒng)稱(chē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)訪(fǎng)問(wè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í)候，通過(guò)設(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ì)有兩種類(lèi)型：一種是物理中斷產(chǎn)生的，包括SError(系統(tǒng)錯(cuò)誤類(lèi)型，包括外部數(shù)據(jù)終止)，IRQ或者FIQ;另一種是虛擬中斷產(chǎn)生的，這種中斷發(fā)生在運(yùn)行在EL2管理者enable的情況下：vSError，vIRQ，vFIQ;
MDSCR_EL1
Monitor Debug System Control Register
