linux-kernel - Re: [PATCHv9 2.6.35-rc4-tip 2/13] uprobes: Breakpoint insertion/removal in user space applications.

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: <1280923528.1923.1058.camel@laptop>
Date:	Wed, 04 Aug 2010 14:05:28 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
Cc:	Christoph Hellwig <hch@...radead.org>, Ingo Molnar <mingo@...e.hu>,
	Steven Rostedt <rostedt@...dmis.org>,
	Randy Dunlap <rdunlap@...otime.net>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Mark Wielaard <mjw@...hat.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Naren A Devaiah <naren.devaiah@...ibm.com>,
	Jim Keniston <jkenisto@...ux.vnet.ibm.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [PATCHv9 2.6.35-rc4-tip 2/13]  uprobes: Breakpoint
 insertion/removal in user space applications.

On Tue, 2010-07-20 at 12:52 +0530, Srikar Dronamraju wrote:
> > Just wondering why these are function pointers.  Do we exepect an
> > architecture to provide different versions of these for say 32 vs 64-bit
> > binaries?  If not just making these arch provided helpers might be a lot
> > simpler.  Especially in the current version where only very few of these
> > are overriden by the architecture at all.
> > 
> > > +unsigned long uprobes_read_vm(struct task_struct *tsk, void __user *vaddr,
> > > +                                   void *kbuf, unsigned long nbytes)
> 
> 
> Some of these functions are purely optional example being
> validate_address. 
> 
> Some of these functions need not be defined by the architecture in
> which case we default to the functions defined in common code. 
> examples being: read_opcode, set_bkpt, and set_orig_insn.
> 
> Some of these functions are architecture mode specific, for example 
> there is a architecture specific pre_xol needed for x86_64. However
> generic pre_xol for x86_32 would suffice for x86_32.
> 
> Some of these functions need to be mandatorily defined by the
> architecture. example being set_ip and analyze_insn.
> 
> Apart from the above flexibilities and enforcements that we can make
> when we use function pointers, its would be handy to incorporate
> more enhancements like return probes and booster. 

Still not sure why you're using this vector though, why not use weak
function for optionals and defaults and no implementation for mandatory
functions (and if the implementations fails to provide it, that will
result in a link error).

Are there likely to be multiple different versions of this method vector
around on a running kernel?
--
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/