Message-ID: <alpine.DEB.1.10.0906131031570.29895@vinegar-pot.mit.edu>
Date:	Tue, 16 Jun 2009 15:50:52 -0400 (EDT)
From:	Tim Abbott <tabbott@...lice.com>
To:	Masami Hiramatsu <mhiramat@...hat.com>
cc:	Ingo Molnar <mingo@...e.hu>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	lkml <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Jim Keniston <jkenisto@...ibm.com>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	Christoph Hellwig <hch@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Anders Kaseorg <andersk@...lice.com>,
	systemtap <systemtap@...rces.redhat.com>,
	DLE <dle-develop@...ts.sourceforge.net>
Subject: Re: [RFC][ PATCH -tip 0/6] kprobes: Kprobes jump optimization
 support

On Fri, 12 Jun 2009, Masami Hiramatsu wrote:

>  - Safety check
[...]
>   Next, Kprobes decodes whole body of probed function and checks there is
>  NO indirect jump, and near jump which jumps into the optimized region (except
>  the 1st byte of jump), because if some jump instruction jumps into the middle
>  of another instruction, it causes unexpected results too.

Hi Masami,

I think your safety check algorithm is wrong.

There are several ways in which the kernel might jump into the optimized 
region that cannot be detected by examining just the probed function:

(1) The compiler is allowed to do cross-function optimization within a 
compilation unit where code in one function jumps into the middle of 
another function.

(2) If you have a switch statement that looks like:

	switch (foo) {
	case 1:
		printk("a1");
		break;
	case 2:
		printk("a2");
		break;
	case 3:
		printk("a3");
		break;
	case 4:
		printk("a4");
		break;
	case 5:
		printk("a5");
		break;
	}

(i.e. a large number of cases indexed by a small range of integers; 
depending on your compiler you may need more cases), gcc will implement it 
using a jump table in the .rodata section.  On x86_32, the generated 
assembly for the switch will read from the jump table at an offset of 
4 * (foo - 1) and then jump to that address to reach the code for the 
appropriate case.  These jump tables can result in jumps from within the 
probed function into the optimized region in a way that your algorithm 
would not detect.

(3) If the code that you're overwriting can throw an exception, it might 
be that that there is a jump from the .fixup section back into the probed 
function that overlaps the optimized region.


The other comment I have about this approach is that it seems you've 
written a completely new x86 disassembler in order to do binary code 
analysis in the kernel.

Ksplice has been using the udis86 disassembler for this purpose: 
<http://udis86.sourceforge.net/>.  udis86 is intended for binary code 
analysis and is designed to be embedded into kernels and other 
applications.

udis86 generates all its instruction table data from an XML opcode file, 
which is I think what H. Peter Anvin was suggesting you should do in this 
previous thread on your instruction decoder: 
<http://lkml.indiana.edu/hypermail/linux/kernel/0904.0/01929.html> 
Compared to e.g. libopcodes it is still quite small -- there's a total of 
about 3000 lines of C, plus some instruction tables that are automatically 
generated from an XML description of the instructions.

The upstream developer has merged patches from Anders Kaseorg and myself 
that make it build as part of the core Linux kernel without any changes 
other than adding a kernel Makefile.  I think if we're going to putting an 
x86 disassembler into the kernel, it might be better to use something like 
udis86 that provides a little more information about the instructions 
being disassembled and is more data-driven.

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

Powered by blists - more mailing lists