x86: WARN_ON breakpoints from .kprobes.text section

Identify breakpoints in .kprobes.text section. These certainly aren't kprobe traps. However, we make an exception for the breakpoint hardcoded into jprobe_return.

---

index 45f2949..f3d13d0 100644
@@ -961,6 +961,7 @@ int __kprobes kprobe_exceptions_notify(struct notifier_block *self,
 				       unsigned long val, void *data)
 {
 	struct die_args *args = data;
+	unsigned long addr = kprobe_bkpt_addr(args->regs);
 	int ret = NOTIFY_DONE;
 
 	if (args->regs && user_mode_vm(args->regs))

@@ -968,7 +969,14 @@ int __kprobes kprobe_exceptions_notify(struct notifier_block *self,
 
 	switch (val) {
 	case DIE_INT3:
-		if (kprobe_handler(args->regs))
+		if (in_kprobes_functions(addr) &&
+		    !is_jprobe_bkpt((u8 *)addr)) {
+			/* A breakpoint has made it's way to the .kprobes.text
+			 * section (excluding jprobe_return). This could be
+			 * due to an external debugger. */
+			WARN_ON(1);
+			
+		} else if (kprobe_handler(args->regs))
 			ret = NOTIFY_STOP;
 		break;
 	case DIE_DEBUG:

Hi Abhishek,

Sorry, I can not understand what issue these patches can solve. The breakpoint which is inserted by external debugger will be checked by kprobe_handler() and be passed to other exception_notify_handlers. In that case, we don't need to warn it.
I think current code is enough simple.

Thank you,

Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: [email protected]

kprobe_handler has a blanket check for all non-kprobe breakpoints. They're all left to the kernel to handle. This is fine. Although external debuggers are free to plant breakpoints anywhere, they should be discouraged from doing so inside .kprobes.text region. Placing them there may lead to recursive page-fault/trap handling. It's a defensive check. I hope I've been able to clarify.

Thanks,
Abhishek Sagar

Hi Abhishek,

Thank you for explanation, I hope I can understand it.
Even if it causes a trap recursively, it could be checked (and ignored) by longjump_break_handler(), and passed to the debugger correctly. Please consider that someone expands jprobe(jprobe2) which uses jprobe_return2() instead of jprobe_return(), how would you handle it? Current kprobes provides an opportunity to those external probe frameworks for checking it by themselves.

By the way, external kernel debugger knows how kprobes (and exception notifier) works, so I think it can fetch his exception before kprobes does (by tweaking notifier chain, etc).
(I hope all external kernel debuggers take care of it. :-))

Thank you again,

Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: [email protected]

Yes, all non-kprobe breakpoints are left to the kernel to be handled. The objective here is to intercept the trap handling of a certain category of such breakpoints and emit a warning. The premise being that .kprobes.text section is a logical breakpoint-free zone.

By a simple modification of is_jprobe_bkpt() (defined in patch #2 of this series).

Could you clarirfy this with some example. For now I'm assuming that by external probe frameworks you mean kernel modules using kprobes. If they embed breakpoints in their handlers, then they will simply not be caught by this check because thay cannot lie in the .kprobes.text section.

I would image that from a code correctness's point of view it shouldn't matter. In any case, nothing can be done if the kprobe exception notifier is circumvented.

--
Thanks,
Abhishek Sagar

Hi,

Oh, I think I've gotten what misleads you.
The .kprobes.text section is a KPROBES-FREE zone. There may be breakpoints owned by other debuggers and hand-coded breakpoints (like as jprobe_return).

IMO, one of advantages of current logic is that you can add another break_handler-based probe as an module without any patches. Even if someone makes fooprobe which is not a jprobe variant, current logic can treat it correctly.
(Another advantage is the performance. Current logic checks only if there is a
running kprobe and there is no kprobes related to the trapped address, instead of checking address section every time when each breakpoint is hit.)

Yes, I mentioned it above.

They cannot lie kprobes in the .kprobes.text section, but can put breakpoints by hand. this is the reason why kprobes provides break_handler.

Thanks,
Best Regards,

Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: [email protected]