linux-kernel - Re: [RFC] [PATCH 4/7] Uprobes Implementation

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]

Date:	Fri, 15 Jan 2010 14:38:04 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
Cc:	Jim Keniston <jkenisto@...ibm.com>, Ingo Molnar <mingo@...e.hu>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	utrace-devel <utrace-devel@...hat.com>,
	Mark Wielaard <mjw@...hat.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Maneesh Soni <maneesh@...ibm.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] [PATCH 4/7] Uprobes Implementation

On Fri, 2010-01-15 at 14:16 +0100, Peter Zijlstra wrote:
> On Fri, 2010-01-15 at 18:38 +0530, Srikar Dronamraju wrote:
> > * Peter Zijlstra <peterz@...radead.org> [2010-01-15 11:33:27]:
> > 
> > > 
> > > > Uprobes layer would need to be notified of process life-time events
> > > > like fork/clone/exec/exit. 
> > > 
> > > No so much the process lifetimes as the vma life times are interesting,
> > > placing a hook in the vm code to track that isn't too hard, 
> > > 
> > > > It also needs to know
> > > > 	-  when a breakpoint is hit
> > > > 	-  stop and resume a thread.
> > > 
> > > A simple hook in the trap code is done quickly enough, and no reason to
> > > stop the thread, its not going anywhere when it traps.
> > > 
> > > 
> > 
> > Some of the threads could be executing in the vicinity of the
> > breakpoint when it is getting inserted or deleted. Wont we need to
> > stop/quiesce those threads?
> 
> The easy answer it so use kstopmachine to patch the code, the slightly
> more complex would be using something like:
> 
>   http://lkml.org/lkml/2010/1/12/300

Also, since its userspace, can't you simply play games with the
pagetables? CoW a new private copy of the page and flip the pagetables
around to the new one, then flush the pagetables on all relevant cpus
and bob's your uncle.

(You might have to play some games with making the page RO to trap
intermediate accesses, but that should work I think)

--
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/