linux-kernel - Re: [RFC] [PATCH 2.6.37-rc5-tip 13/20] 13: x86: x86 specific probe handling

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: <1296203798.15234.249.camel@laptop>
Date:	Fri, 28 Jan 2011 09:36:38 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Roland McGrath <roland@...hat.com>
Cc:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	Ingo Molnar <mingo@...e.hu>,
	Steven Rostedt <rostedt@...dmis.org>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Christoph Hellwig <hch@...radead.org>,
	Andi Kleen <andi@...stfloor.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	SystemTap <systemtap@...rces.redhat.com>,
	Jim Keniston <jkenisto@...ux.vnet.ibm.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [RFC] [PATCH 2.6.37-rc5-tip 13/20] 13: x86: x86 specific probe
 handling

On Thu, 2011-01-27 at 22:23 -0800, Roland McGrath wrote:
> > Uprobes doesn't request/handle block-step for now. So can we postpone
> > your suggested changes till uprobes needs to handle block-step?
> 
> That's not the issue.  The way the hardware works is that if the bit is set
> in the MSR, then the TF eflags bit means block-step instead of single-step.
> So if PTRACE_SINGLEBLOCK has been used (i.e. user_enable_block_step), then
> this can interfere with your use of single-step.  You need to do the work
> in the else branch of step.c:enable_step to ensure that the hardware is not
> left in the state where it will do block-step instead of single-step when
> uprobes wants a single-step done. 

And reset the hardware back to block step when done, and provide the
actual break blockstep would have.

Suppose you hit a breakpoint on the return path while the user it
debugging in blockstep mode, that should all just work.

So there you trap on the return, switch to single step to execute the
return out of line, when done you need to actually break to userspace
since its the end of a block, as well as reset block mode.
--
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/