kprobe注册含RIP寄存器指令返回EINVAL(-22)错误原因咨询

Great question—this is a known limitation in the 3.10 x86_64 kernel's kprobe implementation, and it's directly tied to how RIP-relative addressing interacts with kprobe's breakpoint mechanism. Let's break this down clearly:

Root Cause #

Kprobe works by replacing your target instruction with an int3 breakpoint. When the CPU hits this breakpoint, kprobe runs your pre_handler, then emulates the original instruction, and finally executes your post_handler.

The problem with RIP-relative instructions (like your mov 0x21bd(%rip),%eax) is that their memory operands are calculated using the current value of RIP. When kprobe swaps the original instruction for int3, the RIP value at execution time points to the breakpoint, not the original instruction's address. Emulating the original RIP-relative instruction would compute the wrong memory address (since RIP is now offset by the breakpoint), leading to crashes or unpredictable behavior.

To avoid this risk, the 3.10 kernel's kprobe explicitly blocks registration on RIP-relative instructions, hence the -EINVAL error you're encountering.

Your Specific Case #

Looking at your disassembly:

0xffffffffa33c1085 <test_increment+5>: mov 0x21bd(%rip),%eax # 0xffffffffa33c3248
0xffffffffa33c109b <test_increment+27>: mov %esi,0x21a7(%rip) # 0xffffffffa33c3248

Both instructions use RIP-relative addressing to access the global race variable. These are exactly the type of instructions the 3.10 kprobe implementation rejects.

Solutions #

Here are practical ways to work around this:

• Probe adjacent non-RIP-relative instructions: Pick an instruction right before or after the problematic ones that doesn't rely on RIP addressing. For example, you could target test_increment+11 (push %rbp) or test_increment+22 (lea 0x1(%rax),%esi). Modify your code to set kp->addr = sym_addr + 0xb; (for the push instruction) and it should register successfully.
• Use kretprobe if function-level tracing suffices: If you don't need to probe those exact instructions, kretprobe can track function entry and exit, which might cover your use case without targeting specific RIP-dependent lines.
• Upgrade your kernel: Newer kernels (4.x and above) fixed this limitation by improving how kprobe emulates RIP-relative instructions. If possible, upgrading would let you probe these instructions directly.

Verification #

If you want to confirm this in the kernel source, check the arch/x86/kernel/kprobes.c file in the 3.10 kernel. The code that checks for RIP-relative instructions lives in functions like __copy_instruction or check_kprobe_address, where it detects instruction formats relying on RIP and returns an error.

内容的提问来源于stack exchange，提问作者Abubaker Siddique