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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20091117013617.GF5293@nowhere>
Date:	Tue, 17 Nov 2009 02:36:19 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	"K.Prasad" <prasad@...ux.vnet.ibm.com>
Cc:	Ingo Molnar <mingo@...e.hu>, LKML <linux-kernel@...r.kernel.org>,
	Li Zefan <lizf@...fujitsu.com>,
	Alan Stern <stern@...land.harvard.edu>,
	Peter Zijlstra <peterz@...radead.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Jan Kiszka <jan.kiszka@....de>,
	Jiri Slaby <jirislaby@...il.com>, Avi Kivity <avi@...hat.com>,
	Paul Mackerras <paulus@...ba.org>,
	Mike Galbraith <efault@....de>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Paul Mundt <lethal@...ux-sh.org>,
	Arjan van de Ven <arjan@...ux.intel.com>, paulus@...ibm.com
Subject: Re: [PATCH 5/7 v6] hw-breakpoints: Rewrite the hw-breakpoints
	layer on top of perf events

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/