Kprobes源码分析----kprobe的处理

    在探测点注册kprobe后，会在执行到探测点的指令时触发断点异常（trap 3）。kprobes在断点异常的通知链die_chain上注册了自己的处理函数，这个函数就是kprobe_exception_notify()。kprobe_exception_notify()不仅会接收到断点异常的通知，还会接收到调试异常（trap 1）和保护异常的通知。这篇文章主要围绕这个函数的处理来展开。

    1.断点异常处理

---

   断点是int 3指令触发的，系统中这个异常是由int3()函数来处理，这个函数在entry_32.S中定义。断点异常的处理函数int3()是在trap_init()中注册，注册的时候使用的门类型是中断门，这意味着在处理断点异常时是要关闭中断的，这和普通的异常处理是不同的。在关中断的情况下，CPU仍然可以接收到NMI和CPU引发的异常，包括断点异常。

    int3()中主要是调用do_int3()在处理。do_int3()中在由内核处理前，会通知注册在die_chian通知链上的模块，如果这个异常由内核其他模块处理，内核就不再处理了，源码如下所示：

dotraplinkage void __kprobes do_int3( struct pt_regs *regs, long error_code)
{
# ifdef CONFIG_KPROBES
    if (notify_die(DIE_INT3, "int3", regs, error_code, 3, SIGTRAP)
            == NOTIFY_STOP)
        return;
# else
    if (notify_die(DIE_TRAP, "int3", regs, error_code, 3, SIGTRAP)
            == NOTIFY_STOP)
        return;
# endif

    preempt_conditional_sti(regs);
    do_trap( 3, SIGTRAP, "int3", regs, error_code, NULL);
    preempt_conditional_cli(regs);
}

    如果断点异常是由kprobe引发的， kprobe_exception_notify()会返回NOTIFY_STOP，不再由内核处理。通过前面的分析，我们可以看出 kprobe_exception_notify()是在关中断的情况下调用的，所以这个函数的处理要尽可能地短，不能发生调度，也不能出现会导致睡眠的操作（例如获取互斥锁或信号量）。

    断点异常发生时，通知链上的通知类型为DIE_INT3，这种类型在kprobe_exception_notify()中会调用kprobe_handler()来处理，如下所示：

int __kprobes kprobe_exceptions_notify( struct notifier_block *self,
                       unsigned long val, void *data)
{
......
    switch (val) {
    case DIE_INT3 :
        if (kprobe_handler(args - >regs))
            ret = NOTIFY_STOP;
        break;
    case DIE_DEBUG :
......
    return ret;
}

    kprobe_handler()中会处理普通的kprobe处理流程，即调用pre_handler接口，然后开始单步执行指令。由于在调用kprobe的handler的时候，handler中有可能会触发断点异常（虽然是关闭了中断，但是异常还是会处理的），所以kprobe_handler()也要处理kprobe重入的问题。重入的问题，这里我们只关注普通的kprobe处理流程，代码如下所示：

static int __kprobes kprobe_handler( struct pt_regs *regs)
{
    kprobe_opcode_t *addr;
    struct kprobe *p;
    struct kprobe_ctlblk *kcb;

    addr = (kprobe_opcode_t *)(regs - >ip - sizeof(kprobe_opcode_t));
    if ( *addr != BREAKPOINT_INSTRUCTION) {
        /*
         * The breakpoint instruction was removed right
         * after we hit it.  Another cpu has removed
         * either a probepoint or a debugger breakpoint
         * at this address.  In either case, no further
         * handling of this interrupt is appropriate.
         * Back up over the (now missing) int3 and run
         * the original instruction.
         */
        regs - >ip = ( unsigned long)addr;
        return 1;
    }

    /*
     * We don't want to be preempted for the entire
     * duration of kprobe processing. We conditionally
     * re-enable preemption at the end of this function,
     * and also in reenter_kprobe() and setup_singlestep().
     */
    preempt_disable();

    kcb = get_kprobe_ctlblk();
    p = get_kprobe(addr);

    if (p) {
        if (kprobe_running()) {
                    .......
        } else {
            set_current_kprobe(p, regs, kcb);
            kcb - >kprobe_status = KPROBE_HIT_ACTIVE;

            /*
             * If we have no pre-handler or it returned 0, we
             * continue with normal processing.  If we have a
             * pre-handler and it returned non-zero, it prepped
             * for calling the break_handler below on re-entry
             * for jprobe processing, so get out doing nothing
             * more here.
             */
            if ( !p - >pre_handler || !p - >pre_handler(p, regs))
                setup_singlestep(p, regs, kcb);
            return 1;
        }
    } else if (kprobe_running()) {
        ......
    } /* else: not a kprobe fault; let the kernel handle it */

    preempt_enable_no_resched();
    return 0;
}

    执行完断点指令后，指令指针IP会指向下一个指令的位置，所以这里要使用regs->ip减去断点指令的长度，得到断点指令的地址，存在局部变量addr中。如果addr处的指令不是断点指令，kprobes就不会再处理了，将指令指针指向探测点的位置，然后返回。断点异常处理后，CPU会从addr处的指令开始执行。这种情况可能是断点指令在发生断点异常后被另一个CPU移除，或者是探测点被禁止。

    如果断点指令没有被移除，则kprobes会继续处理。kprobes会首先调用get_kprobe_ctlblk()获取kprobe控制块，获取的变量是一个per-cpu变量，这个变量中会存储kprobe处理的状态，还有可能保存处理kprobe时的寄存器信息等。

    接着会调用get_kprobe()获取addr的位置注册的kprobe。如果kprobe不存在，并且没有kprobe正在处理，则表示addr的位置没有注册kprobe，并且也不是jprobes的处理（kprobe不存在，但是有kprobe正在处理）。

    如果addr处有一个对应的kprobe，则会调用set_current_kprobe()将addr处的kprobe设置到per-cpu变量current_kprobe中，并且把TF（单步执行）和IF（开关中断）标志保存到kprobe控制块中。将kprobe变量保存到current_kprobe中，这样就可以通过这个变量来判断是否当前CPU上正在处理kprobe。

    在kprobe的处理过程中要记录当前kprobe处理的状态，在调用pre_handler之前，状态会设置为KPROBE_HIT_ACTIVE。

    如果在注册kprobe时指定了pre_handler接口，则会调用用户指定的接口。如果pre_handler接口返回1，则不会进行单步执行的过程，post_handler接口也不会被调用（依赖于单步执行过程），直接结束kprobe的处理。

    2.单步执行

---

    单步执行由setup_singlestep()函数来启动，它做的主要工作就是调用prepare_singlestep()来为单步执行做准备，然后把kprobe的处理状态变为KPROBE_HIT_SS，如下所示：

static void __kprobes setup_singlestep( struct kprobe *p, struct pt_regs *regs,
                       struct kprobe_ctlblk *kcb)
{
.......
    prepare_singlestep(p, regs);
    kcb - >kprobe_status = KPROBE_HIT_SS;
}

    prepare_singlesetp()中的处理也很简单，主要是将标志寄存器的TF标志位置1，然后就是设置单步执行指令的地址。如果原始的指令就是断点指令，会将指令指针指向探测点的位置；如果不是，则从保存的指令开始。如果原始的指令真的是断点指令，则会发生kprobe重入，重入时的处理后面再讲，这里先跳过。

     3.调试异常处理

---

    TF标志置1时，CPU每执行完一条指令就产生调试异常（trap 1）。调试异常由debug()函数处理，该函数在entry_32.S中定义，主要是调用do_debug()函数来完成的。do_debug()中会通知注册在die_chian通知链上模块，通知的类型为DIE_DEBUG。Kprobes注册的处理函数仍然是kprobe_exception_notify()，对应的处理如下所示：

int __kprobes kprobe_exceptions_notify( struct notifier_block *self,
                       unsigned long val, void *data)
{
        ......
    switch (val) {
        .......
    case DIE_DEBUG :
        if (post_kprobe_handler(args - >regs))
            ret = NOTIFY_STOP;
        break;
    .......
    return ret;
}

    post_kprobe_handler()中主要是恢复原来的处理流程，并且会调用注册时指定的post_handler接口，源码如下所示：

static int __kprobes post_kprobe_handler( struct pt_regs *regs)
{
        .......
    resume_execution(cur, regs, kcb);
    regs - >flags |= kcb - >kprobe_saved_flags;

    if ((kcb - >kprobe_status != KPROBE_REENTER) && cur - >post_handler) {
        kcb - >kprobe_status = KPROBE_HIT_SSDONE;
        cur - >post_handler(cur, regs, 0);
    }
        .......
    reset_current_kprobe();
        .......

    return 1;
}

    为了在异常处理后从探测点之后开始执行，在这里需要调用resume_execution()来将指令指针IP指向探测点之后的位置，在resume_execution()中还会清除TF标志。在kprobe处理完成后，要恢复之前保存的寄存器标志位，这里主要是TF和IF标志。

    如果kprobe控制块的状态是KPROBE_REENTER，即发生了kprobe重入，则不会调用指定的post_handler接口。

    在调用完指定的post_handler接口后，kprobe的处理就完成了。最后调用reset_current_kprobe()将current_kprobe(per-cpu变量)置为NULL，表示kprobe的处理完成了。

    4.kprobe重入

---

    kprobe重入是指在kprobe的处理过程中又触发了断点异常，这种情况有可能是用户指定的pre_handler或post_handler接口，或者探测点处的指令本身就是断点指令。

    如果第二次发生断点异常的位置没有注册kprobe，kprobe_handler()中会调用正在处理的kprobe的break_handler接口，源码如下所示：

static int __kprobes kprobe_handler( struct pt_regs *regs)
{
    ......
    p = get_kprobe(addr);

    if (p) {
        .......
    } else if (kprobe_running()) {
        p = __get_cpu_var(current_kprobe);
        if (p - >break_handler && p - >break_handler(p, regs)) {
            setup_singlestep(p, regs, kcb);
            return 1;
        }
    } /* else: not a kprobe fault; let the kernel handle it */
        .......
    return 0;
}

    如果指定了break_handler接口并且返回1，则会开始单步执行保存的指令，顺着普通的kprobe流程继续处理。如果在处理kprobe的过程中又发生了断点异常，这也算是一种“异常”（jprobes就利用了这点，或者是专门为jprobes准备的），这种情况需要由break_handler接口来处理。如果处理成功，即返回1，则表示可以继续处理。

    如果第二次发生断点异常的位置也注册了kprobe，kprobe_handler()中会调用reenter_kprobe()来处理，源码如下所示：

static int __kprobes reenter_kprobe( struct kprobe *p, struct pt_regs *regs,
                     struct kprobe_ctlblk *kcb)
{
    switch (kcb - >kprobe_status) {
    case KPROBE_HIT_SSDONE :
# ifdef CONFIG_X86_64
        /* TODO: Provide re-entrancy from post_kprobes_handler() and
         * avoid exception stack corruption while single-stepping on
         * the instruction of the new probe.
         */
        arch_disarm_kprobe(p);
        regs - >ip = ( unsigned long)p - >addr;
        reset_current_kprobe();
        preempt_enable_no_resched();
        break;
# endif
    case KPROBE_HIT_ACTIVE :
        save_previous_kprobe(kcb);
        set_current_kprobe(p, regs, kcb);
        kprobes_inc_nmissed_count(p);
        prepare_singlestep(p, regs);
        kcb - >kprobe_status = KPROBE_REENTER;
        break;
    case KPROBE_HIT_SS :
        if (p == kprobe_running()) {
            regs - >flags &= ~X86_EFLAGS_TF;
            regs - >flags |= kcb - >kprobe_saved_flags;
            return 0;
        } else {
            /* A probe has been hit in the codepath leading up
             * to, or just after, single-stepping of a probed
             * instruction. This entire codepath should strictly
             * reside in .kprobes.text section. Raise a warning
             * to highlight this peculiar case.
             */
        }
    default :
        /* impossible cases */
        WARN_ON( 1);
        return 0;
    }

    return 1;
}

    reenter_kprobe()中会根据当前kprobe处理的状态（kcb->kprobe_status）来做具体的处理。

    如果是KPROBE_HIT_SSDONE状态，说明是在调试异常中调用用户指定的post_handler接口时，第二次触发了断点异常，相当于是断点异常把调试异常给中断了。如果不是X86-64环境，处理和KPROBE_HIT_ACTIVE状态的处理一样。根据代码中的TODO注释，x86-64环境中单步执行新的kprobe指令时会导致异常栈崩溃，具体的原因现在不清楚，如果有知道的，麻烦告知一下。如果是在x86-64下，会调用arch_disarm_kprobe()将触发二次断点异常的kprobe设置的断点指令恢复成原始的指令，相当于是把当前处理的kprobe给禁止掉。然后将指令指针指向触发二次异常的探测点位置（此时已经没有kprobe设置的断点指令），并且调用reset_current_kprobe()将current_kprobe设置为NULL，这样前一个kprobe的处理相当于也结束了。注意，这里的处理完成后，后面还会回到调试异常的处理中，也就是返回到post_kprobe_handler()函数中。

    如果是KPROBE_HIT_ACTIVE状态，是在调用pre_handler接口时触发的断点异常。这种情况下会调用save_previous_kprobe()将前一个kprobe的信息保存到kprobe控制块kprobe_ctlblk（per-cpu变量）中，接着会调用set_current_kprobe()将当前处理的kprobe设置到current_kprobe中，最后开始单步执行新的kprobe处的指令。由于发生了kprobe重入，所以要将kprobe控制块的状态设置为KPROBE_REENTER。此时要开始新的kprobe的处理，把前一个kprobe的处理给挂起了，后面的处理流程和普通的kprobe处理流程相同。在当前的kprobe处理完成后，会继续前一个kprobe的处理，但是由于发生了重入，所以前一个kprobe的post_handler接口就不会调用了。

    如果是KPROBE_HIT_SS，是在单步执行保存的探测点指令时触发的断点异常。如果触发断点异常的指令就是探测点处的指令，此时处理的kprobe和kprobe_running()返回的kprobe是同一个，这样情况下会取消单步执行，恢复保存的寄存器标志。此时会返回0，表示由内核来处理这种情况，因为这个指令不是krobe设置上去的。如果在探测点之后的指令中，这种函数是不应该被探测的，应该放在.kprobes.text section中。此时kprobes会产生一个警告，并且返回0，由内核来处理这种情况。