Re: [PATCH 5/7 v6] hw-breakpoints: Rewrite the hw-breakpointslayer on top of perf events

[Frederic Weisbecker]

On Thu, Nov 12, 2009 at 09:55:02AM +0530, K.Prasad wrote:
> 
> I forgot to mention another potential bug here...
> 
> static int ptrace_write_dr7(struct task_struct *tsk, unsigned long data)
> {
> ..
> ...
> restore:
> 	/*
> 	 * Loop through all the hardware breakpoints, making the
> 	 * appropriate changes to each.
> 	 */
> 	for (i = 0; i < HBP_NUM; i++) {
> 		enabled = decode_dr7(data, i, &len, &type);
> 		bp = thread->ptrace_bps[i];
> 
> 		if (!enabled) {
> 			if (bp) {
> 				/*
> 				 * Don't unregister the breakpoints right-away,
> 				 * unless all register_user_hw_breakpoint()
> 				 * requests have succeeded. This prevents
> 				 * any window of opportunity for debug
> 				 * register grabbing by other users.
> 				 */
> 				if (!second_pass)
> 					continue;
> 				thread->ptrace_bps[i] = NULL;
> 				unregister_hw_breakpoint(bp);
> 			}
> 			continue;
> 		}
> 
> So, the breakpoint is unregistered whenever bits corresponding to
> DR0-DR3 are set to a disabled state in DR7.
> 
> 		/*
> 		 * We shoud have at least an inactive breakpoint at this
> 		 * slot. It means the user is writing dr7 without having
> 		 * written the address register first
> 		 */
> 		if (!bp) {
> 			rc = -EINVAL;
> 			break;
> 		}
> ..
> ...
> }
> 
> Now think of the following sequence of write operations through ptrace:
> 1. Populate address in DRn (where 0 <= n <= 3) (breakpoint registration)
> 2. Enable corresponding bits in DR7 (modify breakpoint to active state)
> 3. Disable bits in DR7 (unregister breakpoint)
> 4. Enable bits in DR7 (returns with failure)
> 
> The assumption that every 'enable' operation in DR7 is preceded by a
> write operation on DR0-DR3 need not be always true.


Right. It just works with gdb because it usually rewrite the whole
sequence while reactivating a breakpoint (addr rewrite + dr7 enable).

But still you're right in that this is buggy. The use of an array
of struct arch_hw_breakpoint per thread should solve it.

Thanks.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/