linux-kernel - Re: [PATCH v3 0/10] Uprobes v3

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 12 May 2010 10:46:29 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:	Ananth N Mavinakayanahalli <ananth@...ibm.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	Ingo Molnar <mingo@...e.hu>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Mel Gorman <mel@....ul.ie>,
	Randy Dunlap <rdunlap@...otime.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Roland McGrath <roland@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, Oleg Nesterov <oleg@...hat.com>,
	Mark Wielaard <mjw@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Jim Keniston <jkenisto@...ux.vnet.ibm.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Hugh Dickins <hugh.dickins@...cali.co.uk>,
	Rik van Riel <riel@...hat.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [PATCH v3 0/10] Uprobes v3

* Ananth N Mavinakayanahalli (ananth@...ibm.com) wrote:
> On Wed, May 12, 2010 at 03:39:20PM +0200, Peter Zijlstra wrote:
> > On Wed, 2010-05-12 at 18:57 +0530, Ananth N Mavinakayanahalli wrote:
> > > Now, as long as we have the housekeeping code to handle the
> > > possibility of a thread hitting the said breakpoint when its being
> > > removed, is it safe to assume atomicity for replacing one byte of
> > > possibly a longer instruction? 
> > 
> > Dunno I'm not a hardware guy, but the issue is so simple to side-step
> > I'm not sure why you're arguing for relying on these special semantics.
> 
> Yes we know what to do, but I am just trying to get clarity if its
> possible at all, since Mathieu was pretty sure that the hoops aren't
> necessary...

>From what I gathered in the Intel code modification documentation, setting a
breakpoint instruction is both atomic and OK with respect to concurrent CPUs
executing the code. The breakpoint instruction itself deals with serialization
of remote cores when it is hit.

Placing back _the original instruction_ is considered as safe too, as it is both
atomic and brings back the remote cores to the original code state. Basically,
these cores either observe the int3, or the original code. If they observe the
int3, they perform core serialization. If they observe the original code, they
either have never observed the int3 version (which is fine, it is as if the code
had never changed), or if they did observe the int3, they executed the
serialization instruction at the int3, so it's OK to put back the original
instruction.

Now the tricky case is the sequence: instruction A -> int3 -> instruction B,
because a core can only see "instruction A -> instruction B" without any
core synchronization whatsoever, and may not see the int3. That's where the
djprobes logic (with IPIs to all cores) comes into play. But as long as we stick
to "insn A -> int3 -> insn A", things can be done very simply.

By the way, kprobes rely on the assumption that it is OK to put a breakpoint
atomically and to put back the original instruction afterward.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
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/