前一篇博文介绍了kprobes的原理与kprobe的使用与实现方式，本文介绍kprobes中的另外一种探測技术jprobe。它基于kprobe实现，不能在函数的任何位置插入探測点，仅仅能在函数的入口处探測。一般用于监測函数的入參值。本文首先通过一个简单的演示样例介绍jprobe的使用方式。然后通过源代码具体分析jprobe的实现流程。
内核源代码：Linux-4.1.x
实验环境：Fedora25（x86_64）、树莓派1b
1、jprobe使用实例
使用jprobe探測函数的入參值，须要编写内核模块。同kprobe一样，内核相同提供了jprobe的实例程序jprobe_example.c（位于sample/kprobes文件夹），该程序实现了探測do_fork函数入參的功能，用户能够以它为模板来探測其它函数（当然不是说什么函数都能探測的。限制同kprobe一样，另外须要注意的是一个被探測函数仅仅能注冊一个jprobe）。
在分析jprobe_example.c之前先熟悉一下jprobe的基本结构与API接口。
1.1、jprobe结构体与API介绍
struct jprobe结构体定义例如以下：
/*
* Special probe type that uses setjmp-longjmp type tricks to resume
* execution at a specified entry with a matching prototype corresponding
* to the probed function - a trick to enable arguments to become
* accessible seamlessly by probe handling logic.
* Note:
* Because of the way compilers allocate stack space for local variables
* etc upfront, regardless of sub-scopes within a function, this mirroring
* principle currently works only for probes placed on function entry points.
*/
struct jprobe {
struct kprobe kp;
void *entry; /* probe handling code to jump to */
};该结构很的简单，仅包括了一个kprobe结构（由于它是基于kprobe实现的）和一个entry指针。它保存的是探測点运行回调函数的地址。当触发调用被探測函数时。保存到该指针的地址会作为目标地址跳转运行（probe handling code to jump to），因此用户指定的探測函数得以运行。
相关的API例如以下：
int register_jprobe(struct jprobe *jp) //向内核注冊jprobe探測点 void unregister_jprobe(struct jprobe *jp) //卸载jprobe探測点 int register_jprobes(struct jprobe **jps, int num) //注冊探測函数向量，包括多个不同探測点 void unregister_jprobes(struct jprobe **jps, int num) //卸载探測函数向量，包括多个不同探測点 int disable_jprobe(struct jprobe *jp) //暂时暂停指定探測点的探測 int enable_jprobe(struct jprobe *jp) //恢复指定探測点的探測
1.2、演示样例jprobe_example分析与演示
同kprobe_example.c一样，该演示样例程序仍以do_fork作为被探測函数进行探測。
当创建进程时，探測函数会调用它打印出do_fork函数的入參值。以下具体分析：
static struct jprobe my_jprobe = {
.entry = jdo_fork,
.kp = {
.symbol_name = "do_fork",
},
};
static int __init jprobe_init(void)
{
int ret;
ret = register_jprobe(&my_jprobe);
if (ret < 0) {
printk(KERN_INFO "register_jprobe failed, returned %d
", ret);
return -1;
}
printk(KERN_INFO "Planted jprobe at %p, handler addr %p
",
my_jprobe.kp.addr, my_jprobe.entry);
return 0;
}
static void __exit jprobe_exit(void)
{
unregister_jprobe(&my_jprobe);
printk(KERN_INFO "jprobe at %p unregistered
", my_jprobe.kp.addr);
}程序定义了一个struct jprobe实例my_jprobe，指定被探測函数的名字是do_fork（能够改动它以达到探測其它函数的目的），然后探測回调函数为jdo_fork。在模块的初始化函数中，调用register_jprobe函数向kprobe子系统注冊my_jprobe，这样jprobe探測默认就启用了，最后在exit函数中调用unregister_jprobe函数卸载。
/* Proxy routine having the same arguments as actual do_fork() routine */
static long jdo_fork(unsigned long clone_flags, unsigned long stack_start,
unsigned long stack_size, int __user *parent_tidptr,
int __user *child_tidptr)
{
pr_info("jprobe: clone_flags = 0x%lx, stack_start = 0x%lx "
"stack_size = 0x%lx
", clone_flags, stack_start, stack_size);
/* Always end with a call to jprobe_return(). */
jprobe_return();
return 0;
}jdo_fork函数也只打印出了在调用do_fork函数时传入的clone_flags、stack_start和stack_size这三个入參值，整个实现很easy直观。可是有两点须要注意：
1）探測回调函数的入參必须同被探測函数的一致。否则无法达到探測函数入參的目的，比如此处的jdo_fork函数入參unsigned long clone_flags、unsigned long stack_start、unsigned long stack_size、int __user *parent_tidptr和int __user *child_tidptr同do_fork函数是全然一致的（注意返回值固定为long类型）。
2）在回调函数运行完成以后，必须调用jprobe_return函数（凝视中也有强调）。否则运行流程就回不到正常的运行流程中了。这一点后文会具体分析。
以下在x86_64环境下演示该程序的实际效果（环境配置请參考前一篇博文）：
<6>[15817.544375] jprobe: clone_flags = 0x1200011, stack_start = 0x0 stack_size = 0x0
<6>[15817.551217] jprobe: clone_flags = 0x1200011, stack_start = 0x0 stack_size = 0x0
<6>[15817.905328] jprobe: clone_flags = 0x1200011, stack_start = 0x0 stack_size = 0x0
<6>[15822.684688] jprobe: clone_flags = 0x1200011, stack_start = 0x0 stack_size = 0x0
<6>[15822.704001] jprobe: clone_flags = 0x1200011, stack_start = 0x0 stack_size = 0x0
在载入jprobe_example.ko模块以后，在终端随便敲几个命令触发进程创建，内核打印出以上message，能够看到do_fork的入參就被很easy的获取到了，其它函数的探測也类似，不再具体描写叙述。
2、jprobe实现分析
jpeobe的实现基于kprobe，因此这里将在前一篇博文《Linux内核调试技术——kprobe使用与实现》的基础之上分析它的实现，述主要包含jprobe注冊流程和触发探測流程，涉及kprobe的部分不再具体描。
2.1、jprobe实现原理
利用kprobe，jprobe是一种特殊形式的kprobe，它有自己的pre_handler和break_handler回调函数。当中pre_handler回调函数负责保存原始调用上下文并为调用用户指定的探測函数jprobe->entry准备环境。然后跳转到jprobe->entry运行（被探測函数的入參信息在此得到输出）。接着再次触发kprobe流程，在break_handler函数中恢复原始上下文，最后返回正常运行流程。
2.2、注冊一个jprobe实例
jprobe探測模块调用register_jprobe函数向内核注冊一个jprobe实例，代码路径kernel/kprobes.c，其主要流程例如以下图：
图1 jpobe注冊流程
int register_jprobe(struct jprobe *jp)
{
return register_jprobes(&jp, 1);
}
EXPORT_SYMBOL_GPL(register_jprobe);
register_jprobe函数仅仅是register_jprobes的一个封装。主要注冊功能由register_jprobes函数完毕。
int register_jprobes(struct jprobe **jps, int num)
{
struct jprobe *jp;
int ret = 0, i;
if (num <= 0)
return -EINVAL;
for (i = 0; i < num; i++) {
unsigned long addr, offset;
jp = jps[i];
addr = arch_deref_entry_point(jp->entry);
/* Verify probepoint is a function entry point */
if (kallsyms_lookup_size_offset(addr, NULL, &offset) &&
offset == 0) {
jp->kp.pre_handler = setjmp_pre_handler;
jp->kp.break_handler = longjmp_break_handler;
ret = register_kprobe(&jp->kp);
} else
ret = -EINVAL;
if (ret < 0) {
if (i > 0)
unregister_jprobes(jps, i);
break;
}
}
return ret;
}
EXPORT_SYMBOL_GPL(register_jprobes);
函数是一个循环，对每一个jprobe运行同样的注冊流程，首先从jp->entry中取出探測回调函数的地址，对它进行验证。
kallsyms_lookup_size_offset函数的作用是从内核或者模块的符号表中找到addr地址所在的符号，找到后会通过offset值返回addr与符号起始的偏移，这偏移值必须为0，即必须为一个函数的入口。若条件符合。则设置kprobe的pre_handler和break_handler这两个回调函数setjmp_pre_handler和longjmp_break_handler，最后调用register_kprobe函数注冊kprobe。
可见jprobe的注冊流程很的简单。它的本质就是注冊一个kprobe，利用kprobe机制实现探測，仅仅是探測回调函数并不是用户自定义。使用jprobe私有的而已。在注冊完毕后，jprobe（kprobe）机制启动。当函数调用流程运行到被探測函数时就会触发jprobe（kprobe）探測。
最后须要注意的是，jprobe是不能在同一个被探測点注冊多个的，在kprobe的注冊流程register_kprobe->register_aggr_kprobe->add_new_kprobe中会有推断：
if (p->break_handler) {
if (ap->break_handler)
return -EEXIST;2.3、触发jprobe探測
基于kprobe机制，在运行到被探測函数后。会触发CPU异常，依照kprobe的运行流程。由kprobe_handler函数调用到pre_handler回调函数。即setjmp_pre_handler。
该函数架构相关。它依据架构的不同进行一些栈或者寄存器相关的操作，保存现场以备调用结束后恢复，随后跳转到用户定的jprobe->entry处运行。在打印出用户须要的信息后，返回原有正常的流程继续运行。主要流程例如以下图：
图2 jprobe触发流程
2.3.1、arm架构实现
int __kprobes setjmp_pre_handler(struct kprobe *p, struct pt_regs *regs)
{
struct jprobe *jp = container_of(p, struct jprobe, kp);
struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
long sp_addr = regs->ARM_sp;
long cpsr;
kcb->jprobe_saved_regs = *regs;
memcpy(kcb->jprobes_stack, (void *)sp_addr, MIN_STACK_SIZE(sp_addr));
regs->ARM_pc = (long)jp->entry;
cpsr = regs->ARM_cpsr | PSR_I_BIT;
#ifdef CONFIG_THUMB2_KERNEL
/* Set correct Thumb state in cpsr */
if (regs->ARM_pc & 1)
cpsr |= PSR_T_BIT;
else
cpsr &= ~PSR_T_BIT;
#endif
regs->ARM_cpsr = cpsr;
preempt_disable();
return 1;
}首先再次明白入參struct pt_regs *regs的含义是触发CPU异常前所保存的正常运行流上下文的寄存器值。函数首先获取触发的jprobe结构实例，并调用get_kprobe_ctlblk取得当前CPU的kprobe_ctlblk结构全局变量。这个struct kprobe_ctlblk结构定义在kprobe分析中已经见过，只是jprobe使用到了当中定义的另两个字段：
/* per-cpu kprobe control block */
struct kprobe_ctlblk {
unsigned int kprobe_status;
struct prev_kprobe prev_kprobe;
struct pt_regs jprobe_saved_regs;
char jprobes_stack[MAX_STACK_SIZE];
};当中jprobe_saved_regs用于保存寄存器信息，jprobes_stack则用于保存栈信息，它们用于在jprobe返回时恢复调用探測前的上下文，这一点从setjmp_pre_handler函数的前两行就能够看出。先提个问题，为何kprobe不须要保存原上下文信息而jprobe须要？
函数接下来改动传入的ARM_pc值为用户指定的探測回调函数地址，注意这个值本来在正常的kprobe流程中是要被设置为正常流程的下一条指令的（运行完kprobe流程后就会回到原流程继续运行）。这里在kprobe的整个流程结束后就不会回到原流程运行了。而是会进入到用户指定的探測函数运行。
函数然后改动入參的CPSR寄存器值，置位PSR_I_BIT，表示禁用中断，最后禁止抢占并返回1。回到kprobe_handler函数中看返回1后接下来kprobe就不会运行singlestep和调用post_handler回调函数了。注意也不会调用reset_current_kprobe函数复位当前运行的kprobe为NULL：
if (!p->pre_handler || !p->pre_handler(p, regs)) {
kcb->kprobe_status = KPROBE_HIT_SS;
singlestep(p, regs, kcb);
if (p->post_handler) {
kcb->kprobe_status = KPROBE_HIT_SSDONE;
p->post_handler(p, regs, 0);
}
reset_current_kprobe();
}在kprobe_handler流程返回后，运行流程进入到了用户指定的探測函数运行，对于前文中的jprobe_example程序来说就是jdo_fork函数。提第二个问题，被探測函数的入參值是怎样获取的？
从setjmp_pre_handler的实现能够看出。该函数只改动了kprobe的返回地址，并没有改动栈和其它的寄存器值。因此在CPU跳转到jdo_fork运行时，它的寄存器和栈中的内容同原本调用do_fork函数时差点儿是一模一样的（不过禁用了中断而已），因此不论是通过寄存器传參还是通过压栈的方式传參。用户在定义jdo_fork函数时只须要将函数入參定义的同do_fork一样就能够轻轻松松的获取到原有的入參值了。另外从这里的实现能够看出另外一个信息。jprobe的回调运行上下文同原函数运行的上下文是一样的，这点不同于kprobe，kprobe的回调函数运行的上下文是在CPU异常的中断上下文。
最后因为探測函数（jdo_fork）是在kprobe_handler流程运行完毕后跳转运行的，跳过了single_step流程。这也就说它不能利用原有kprobe的机制回到原始运行流程中去运行，须要另想他法，事实上在setjmp_pre_handler函数中保存的寄存器pt_regs就是用于这个目的的。也就解释了前文中提出的第一个问题，接下来具体分析。
回到探測函数jdo_fork中，用户在获取须要的信息后，接下来进入现场恢复的流程，当中的关键部分就是jdo_fork函数最后调用的jprobe_return函数，它是由嵌入汇编实现的
void __kprobes jprobe_return(void)
{
struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
__asm__ __volatile__ (
/*
* Setup an empty pt_regs. Fill SP and PC fields as
* they're needed by longjmp_break_handler.
*
* We allocate some slack between the original SP and start of
* our fabricated regs. To be precise we want to have worst case
* covered which is STMFD with all 16 regs so we allocate 2 *
* sizeof(struct_pt_regs)).
*
* This is to prevent any simulated instruction from writing
* over the regs when they are accessing the stack.
*/
#ifdef CONFIG_THUMB2_KERNEL
...
#else
"sub sp, %0, %1
"
#endif
"ldr r0, ="__stringify(JPROBE_MAGIC_ADDR)"
"
"str %0, [sp, %2]
"
"str r0, [sp, %3]
"
"mov r0, sp
"
"bl kprobe_handler
"
/*
* Return to the context saved by setjmp_pre_handler
* and restored by longjmp_break_handler.
*/
#ifdef CONFIG_THUMB2_KERNEL
...
#else
"ldr r0, [sp, %4]
"
"msr cpsr_cxsf, r0
"
"ldmia sp, {r0 - pc}
"
#endif
:
: "r" (kcb->jprobe_saved_regs.ARM_sp),
"I" (sizeof(struct pt_regs) * 2),
"J" (offsetof(struct pt_regs, ARM_sp)),
"J" (offsetof(struct pt_regs, ARM_pc)),
"J" (offsetof(struct pt_regs, ARM_cpsr)),
"J" (offsetof(struct pt_regs, ARM_lr))
: "memory", "cc");
}这里模拟出了一个假的pt_regs结构体。只填充了当中的sp和pc字段（后文中的longjmp_break_handler函数须要），当中pc的值为JPROBE_MAGIC_ADDR，然后长跳转到kprobe_handler执行，kprobe_handler函数推断当前已经有kprobe正在执行了。因此进入下面调用流程：
} else if (cur) {
/* We probably hit a jprobe. Call its break handler. */
if (cur->break_handler && cur->break_handler(cur, regs)) {
kcb->kprobe_status = KPROBE_HIT_SS;
singlestep(cur, regs, kcb);
if (cur->post_handler) {
kcb->kprobe_status = KPROBE_HIT_SSDONE;
cur->post_handler(cur, regs, 0);
}
}
reset_current_kprobe();首先调用kprobe的break_handler回调函数，即longjmp_break_handler函数：
int __kprobes longjmp_break_handler(struct kprobe *p, struct pt_regs *regs)
{
struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
long stack_addr = kcb->jprobe_saved_regs.ARM_sp;
long orig_sp = regs->ARM_sp;
struct jprobe *jp = container_of(p, struct jprobe, kp);
if (regs->ARM_pc == JPROBE_MAGIC_ADDR) {
if (orig_sp != stack_addr) {
struct pt_regs *saved_regs =
(struct pt_regs *)kcb->jprobe_saved_regs.ARM_sp;
printk("current sp %lx does not match saved sp %lx
",
orig_sp, stack_addr);
printk("Saved registers for jprobe %p
", jp);
show_regs(saved_regs);
printk("Current registers
");
show_regs(regs);
BUG();
}
*regs = kcb->jprobe_saved_regs;
memcpy((void *)stack_addr, kcb->jprobes_stack,
MIN_STACK_SIZE(stack_addr));
preempt_enable_no_resched();
return 1;
}
return 0;
}这个函数非常easy，首先会推断sp的值和保存的sp值是都是一样的。若不一样则报BUG，否则恢复保存在kprobe_ctlblk结构体中的寄存器值和栈，最后启用内核抢占。至此jprobe的处理流程所有完毕，接下来会回到kprobe的kprobe_handler中继续完毕本次kprobe，运行单步运行single_step和post_handler，最后回到原流程运行。由此可见。在用户定义的探測函数末尾。必需要调用jprobe_return函数。否则代码的运行就“飞了”。再也回不到原有的流程中去了。
2.3.2、x86_64架构实现
int setjmp_pre_handler(struct kprobe *p, struct pt_regs *regs)
{
struct jprobe *jp = container_of(p, struct jprobe, kp);
unsigned long addr;
struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
kcb->jprobe_saved_regs = *regs;
kcb->jprobe_saved_sp = stack_addr(regs);
addr = (unsigned long)(kcb->jprobe_saved_sp);
/*
* As Linus pointed out, gcc assumes that the callee
* owns the argument space and could overwrite it, e.g.
* tailcall optimization. So, to be absolutely safe
* we also save and restore enough stack bytes to cover
* the argument area.
*/
memcpy(kcb->jprobes_stack, (kprobe_opcode_t *)addr,
MIN_STACK_SIZE(addr));
regs->flags &= ~X86_EFLAGS_IF;
trace_hardirqs_off();
regs->ip = (unsigned long)(jp->entry);
/*
* jprobes use jprobe_return() which skips the normal return
* path of the function, and this messes up the accounting of the
* function graph tracer to get messed up.
*
* Pause function graph tracing while performing the jprobe function.
*/
pause_graph_tracing();
return 1;
}
NOKPROBE_SYMBOL(setjmp_pre_handler);x86_64架构的实现总体同arm的大同小异，函数首先相同是保存现场。然后关闭中断并设置IP寄存器的值为jp->entry，最后返回1，这样在kprobe_int3_handler函数会跳过single_step。
/* * 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, 0); return 1;于是在kprobe调用流程结束后跳转到用户的探測函数运行。在来看jprobe_return函数的实现：
void jprobe_return(void)
{
struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
asm volatile (
#ifdef CONFIG_X86_64
" xchg %%rbx,%%rsp
"
#else
" xchgl %%ebx,%%esp
"
#endif
" int3
"
" .globl jprobe_return_end
"
" jprobe_return_end:
"
" nop
"::"b"
(kcb->jprobe_saved_sp):"memory");
}同arm的实现不同，这里使用int3指令再次触发CPU3异常，而且异常出的地址已经不再是BREAKPOINT_INSTRUCTION了，所以会进入到kprobe_int3_handler的下面流程运行：
} else if (kprobe_running()) {
p = __this_cpu_read(current_kprobe);
if (p->break_handler && p->break_handler(p, regs)) {
if (!skip_singlestep(p, regs, kcb))
setup_singlestep(p, regs, kcb, 0);
return 1;
}相同是调用kprobe的break_handler回调函数运行，也即是longjmp_break_handler函数。
int longjmp_break_handler(struct kprobe *p, struct pt_regs *regs)
{
struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
u8 *addr = (u8 *) (regs->ip - 1);
struct jprobe *jp = container_of(p, struct jprobe, kp);
void *saved_sp = kcb->jprobe_saved_sp;
if ((addr > (u8 *) jprobe_return) &&
(addr < (u8 *) jprobe_return_end)) {
if (stack_addr(regs) != saved_sp) {
struct pt_regs *saved_regs = &kcb->jprobe_saved_regs;
printk(KERN_ERR
"current sp %p does not match saved sp %p
",
stack_addr(regs), saved_sp);
printk(KERN_ERR "Saved registers for jprobe %p
", jp);
show_regs(saved_regs);
printk(KERN_ERR "Current registers
");
show_regs(regs);
BUG();
}
/* It's OK to start function graph tracing again */
unpause_graph_tracing();
*regs = kcb->jprobe_saved_regs;
memcpy(saved_sp, kcb->jprobes_stack, MIN_STACK_SIZE(saved_sp));
preempt_enable_no_resched();
return 1;
}
return 0;
}longjmp_break_handler函数同arm实现基本一致，恢复代码的原有上下文。打开内核抢占。最后交回给kprobe继续运行后面的single_step和恢复流程。只是值的注意的是第一条推断语句。因为本次int3异常是在jprobe_return函数中触发的。因此longjmp_break_handler函数的struct pt_regs *regs入參值是在调用jprobe_return函数环境上下文中的寄存器值。因此addr一定是在jprobe_return函数的地址范围内，所以以此推断本次调用的有效性，防止误入。
3、总结
jprobe探測技术基于kprobe实现，是kprobes三种探測技术中的另外一种。内核开发者能够用它来探測内核函数的调用以及调用时的入參值，使用很方便。本文介绍了jprobe探測工具的使用方式及其原理，并通过源代码分析了arm架构和x86_64架构下它的实现方式。下一篇博文将介绍kprobes中的最后一种用来探測函数返回值的kretprobe探測技术。