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: <20110127191146.DB22F180999@magilla.sf.frob.com>
Date:	Thu, 27 Jan 2011 11:11:46 -0800 (PST)
From:	Roland McGrath <roland@...hat.com>
To:	Peter Zijlstra <peterz@...radead.org>
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

> But I'll leave this to the x86 people who actually know the intricacies
> of the single step cruft, I was just wondering why you weren't using (or
> extending) the existing code.

The hairy aspects of the step.c code are hairy (and not usable at interrupt
level) because they do some instruction analysis.  Since uprobes already
does its own instruction analysis, reusing step.c's separate hacks makes
less sense to me than integrating knowledge of the single-step vs
pushf/popf issues into the uprobes instruction analysis.

That said, there is further nontriviality just to do with the block-step
support and with not clobbering user-visible usage of TF in eflags, which
uprobes needs to handle as well.  It makes sense to share that code rather
than repeating it, even if that entails changes to the step.c code.

Thanks,
Roland
--
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/