kdb: Add message about CONFIG_DEBUG_RODATA on failure to install breakpoint

On x86, if CONFIG_DEBUG_RODATA is set, one cannot set breakpoints via KDB. Apparently this is a well-known problem, as at least one distribution now ships with both KDB enabled and CONFIG_DEBUG_RODATA=y for security reasons.

This patch just adds an extra printk message to the breakpoint failure case, in order to provide some useful diagnostics to the user.

---
 kernel/debug/kdb/kdb_bp.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

index 20059ef..f015e79 100644
@@ -153,6 +153,10 @@ static int _kdb_bp_install(struct pt_regs *regs, kdb_bp_t *bp)
 	} else {
 		kdb_printf("%s: failed to set breakpoint at 0x%lx\n",
 			   __func__, bp->bp_addr);
+#ifdef CONFIG_DEBUG_RODATA
+		kdb_printf("May need to disable CONFIG_DEBUG_RODATA in order"
+			" to set breakpoints\n");
+#endif
 		return 1;
 	}
 	return 0;

1.6.6

The patch is definitely the right idea. I believe we should try and tell the whole story and only print the message for the type of breakpoint that fails. It is absolutely the case that you can still use kdb/kdb without recompiling the kernel.

I propose a slightly different implementation below.

---

Subject: [PATCH] kdb: Add message about CONFIG_DEBUG_RODATA on failure to install breakpoint

When the kernel config option CONFIG_DEBUG_RODATA=y is set on x86 software breakpoints are not available to KDB. The constraints to debug kernel are often at odds with security protections for a kernel and several OS distributions ship with both KDB enabled and CONFIG_DEBUG_RODATA=y.

This patch adds an printk message to the breakpoint failure case, in order to provide suggestions about how to use the debugger.

---
 kernel/debug/kdb/kdb_bp.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

index 20059ef..8418c2f 100644
@@ -153,7 +153,13 @@ static int _kdb_bp_install(struct pt_regs *regs, kdb_bp_t *bp)
 	} else {
 		kdb_printf("%s: failed to set breakpoint at 0x%lx\n",
 			   __func__, bp->bp_addr);
+#ifdef CONFIG_DEBUG_RODATA
+		if (!bp->bp_type) {
+			kdb_printf("Software breakpoints are unavailable.\n"
+				   "  Change the kernel CONFIG_DEBUG_RODATA=n\n"
+				   "  OR use hw breakpoints: help bph\n");
+		}
+#endif
 		return 1;
 	}
 	return 0;

The new patch looks fine.
-- Tim

=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation Senior Staff Engineer, Sony Network Entertainment
=============================

Thanks. Because you posed the question a while back about potentially changing this such that it works, I thought I might re-open the discussion around further integration with kgdb/kdb and kprobes. Back in 2008 I explained you can "hack it" so as to use copy on write patches, just for the debugger in order to use software breakpoints.

Something horrible like:

@@ -42,11 +43,24 @@ EXPORT_SYMBOL_GPL(probe_kernel_read);
long probe_kernel_write(void *dst, void *src, size_t size)

 {
        long ret;
+#ifdef CONFIG_X86
+       unsigned int level;
+       pte_t *pte = lookup_address((unsigned long)dst, &level);
+       int unprotect = !pte_write(*pte);
+#endif
        mm_segment_t old_fs = get_fs();

[...clipped rest of original hack...]

Obviously we are not going to go down the horrible hack route, so I thought I might look at how the kprobe implementation works, because they do deal with read-only pages. They created a function called text_poke() that is called from arch_arm_probe().

It might be possible to take a short cut and use the arch_arm_probe() directly. Ultimately I would like to consider just using kprobes instead for things like single stepping etc..., but it still has a few problems with atomic reservations. This work had been shelved in back 2010, in favor of merging kdb. I am not sure if anyone wants to take a look at it, but I do think it might warrant some experimentation.

Jason.

To follow up on this and move to closure, I did some investigation and concluded it is possible to use the kprobes API to make use of the text_poke() function.

I sent a patch series out for review with the implementation.

https://lkml.org/lkml/2012/3/21/375

Cheers,
Jason.