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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 12 May 2010 13:59:24 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	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>,
	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

* H. Peter Anvin (hpa@...or.com) wrote:
> On 05/12/2010 07:46 AM, Mathieu Desnoyers wrote:
> > 
> > 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.
> > 
> 
> Keep in mind the following corner case, though:
> 
> insnA -> int3@A -> insnA
> insnB -> int3@B -> insnB
> 
> It is now possible for the core to hit int3@A, without the int3@B being
> there.  The int3 handler *has* to be able to handle any of the int3's
> put in place, quite possibly out of order, until a core serialization is
> performed.

Indeed. I would add that this out-of-order observation of breakpoint
modification is already expected, because other cores may be executing arbitrary
code when we add the two breakpoints (either insnA, B, or somewhere in between,
or somewhere else entirely).

Basically, we can make no assumption about the order in which the two stores
will be seen by other CPUs. But I can't imagine a debugger expecting these two
stores to be observed in order.

If we ever want to provide a _guarantee_ that starting from a certain point all
CPUs will see a set of breakpoint, then we need to issue a core serializing
instruction on all CPUs. This would determine the "quiescent state" of the CPUs,
starting from which all of them see the breakpoints.

Thanks,

Mathieu

> 
> 	-hpa
> 
> -- 
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel.  I don't speak on their behalf.
> 

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