public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@elte.hu>, Steven Rostedt <rostedt@goodmis.org>,
	Randy Dunlap <rdunlap@xenotime.net>,
	Arnaldo Carvalho de Melo <acme@infradead.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	Oleg Nesterov <oleg@redhat.com>, Mark Wielaard <mjw@redhat.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Naren A Devaiah <naren.devaiah@in.ibm.com>,
	Jim Keniston <jkenisto@linux.vnet.ibm.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	"Frank Ch. Eigler" <fche@redhat.com>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [PATCHv11 2.6.36-rc2-tip 4/15]  4: uprobes: x86 specific functions for user space breakpointing.
Date: Fri, 03 Sep 2010 12:26:02 +0200	[thread overview]
Message-ID: <87pqwvm8cl.fsf@basil.nowhere.org> (raw)
In-Reply-To: <20100825134210.5447.10126.sendpatchset@localhost6.localdomain6> (Srikar Dronamraju's message of "Wed, 25 Aug 2010 19:12:10 +0530")

Srikar Dronamraju <srikar@linux.vnet.ibm.com> writes:

Quick high level review. I did not attempt to validate the basic
algorithm, more the kernel interface.

> Provides x86 specific functions for instruction analysis and
> instruction validation and x86 specific pre-processing and
> post-processing of singlestep especially for RIP relative
> instructions. Uses "x86: instruction decoder API" for validation and
> analysis of user space instructions. This analysis is used at the time
> of post-processing of breakpoint hit to do the necessary fix-ups.
> There is support for breakpointing RIP relative instructions. However
> there are still few instructions that cannot be singlestepped.

One general comment here: since with uprobes the instruction
decoder becomes security critical did you do any fuzz tests
on it (e.g. like using it on crashme or on code that has 
been corrupted with a few bitflips) ?

> +typedef u8 user_bkpt_opcode_t;

Maybe it's me, but I would prefer breakpoint instead of bkpt
> +#ifdef CONFIG_X86_32
> +#define is_32bit_app(tsk) 1
> +#else
> +#define is_32bit_app(tsk) (test_tsk_thread_flag(tsk, TIF_IA32))
> +#endif

This probably should be elsewhere.

> +
> +#define UPROBES_FIX_RIP_AX	0x8000
> +#define UPROBES_FIX_RIP_CX	0x4000
> +
> +/* Adaptations for mhiramat x86 decoder v14. */
> +#define OPCODE1(insn) ((insn)->opcode.bytes[0])
> +#define OPCODE2(insn) ((insn)->opcode.bytes[1])
> +#define OPCODE3(insn) ((insn)->opcode.bytes[2])
> +#define MODRM_REG(insn) X86_MODRM_REG(insn->modrm.value)
> +
> +/*
> + * @reg: reflects the saved state of the task
> + * @vaddr: the virtual address to jump to.
> + * Return 0 on success or a -ve number on error.
> + */
> +void set_ip(struct pt_regs *regs, unsigned long vaddr)
> +{
> +	regs->ip = vaddr;
> +}
> +
> +#ifdef CONFIG_X86_64
> +static bool is_riprel_insn(struct user_bkpt *user_bkpt)
> +{
> +	return ((user_bkpt->fixups &
> +			(UPROBES_FIX_RIP_AX | UPROBES_FIX_RIP_CX)) != 0);
> +}
> +

Shouldn't all this stuff be in the instruction decoder? 

It seems weird to have the knowledge spread over multiple files.

> +
> +static void report_bad_prefix(void)
> +{
> +	printk(KERN_ERR "uprobes does not currently support probing "
> +		"instructions with any of the following prefixes: "
> +		"cs:, ds:, es:, ss:, lock:\n");
> +}
> +
> +static void report_bad_1byte_opcode(int mode, user_bkpt_opcode_t op)
> +{
> +	printk(KERN_ERR "In %d-bit apps, "
> +		"uprobes does not currently support probing "
> +		"instructions whose first byte is 0x%2.2x\n", mode, op);
> +}
> +
> +static void report_bad_2byte_opcode(user_bkpt_opcode_t op)
> +{
> +	printk(KERN_ERR "uprobes does not currently support probing "
> +		"instructions with the 2-byte opcode 0x0f 0x%2.2x\n", op);
> +}

These functions that just do a single printk seem weird. I would
do that in the caller. Also the message could be shortened I guess
and should just dump the bytes.

> +
> +/**
> + * analyze_insn - instruction analysis including validity and fixups.
> + * @tsk: the probed task.
> + * @user_bkpt: the probepoint information.
> + * Return 0 on success or a -ve number on error.
> + */
> +int analyze_insn(struct task_struct *tsk, struct user_bkpt *user_bkpt)
> +{
> +	int ret;
> +	struct insn insn;
> +
> +	user_bkpt->fixups = 0;
> +#ifdef CONFIG_X86_64
> +	user_bkpt->arch_info.rip_target_address = 0x0;
> +#endif
> +
> +	if (is_32bit_app(tsk))

This check is not fully correct because it's valid to have
32bit code in 64bit programs and vice versa.  The only good
way to check that is to look at the code segment at runtime
though (and it gets complicated if you want to handle LDTs,
but that could be optional). May be difficult to do though.

Also the compat bit is not necessarily set if no system call is
executing. You would rather need to check the exec_domain.
> + */
> +static int adjust_ret_addr(struct task_struct *tsk, unsigned long sp,
> +							long correction)
> +{
> +	int rasize, ncopied;
> +	long ra = 0;
> +
> +	if (is_32bit_app(tsk))
> +		rasize = 4;
> +	else
> +		rasize = 8;
> +	ncopied = uprobes_read_vm(tsk, (void __user *) sp, &ra, rasize);
> +	if (unlikely(ncopied != rasize))
> +		goto fail;

goto is automatically unlikely and unlikely is deprecated anyways.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

  reply	other threads:[~2010-09-03 10:26 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-25 13:41 [PATCHv11 2.6.36-rc2-tip 0/15] 0: Uprobes Patches Srikar Dronamraju
2010-08-25 13:41 ` [PATCHv11 2.6.36-rc2-tip 1/15] 1: mm: Move replace_page() / write_protect_page() to mm/memory.c Srikar Dronamraju
2010-08-25 13:41 ` [PATCHv11 2.6.36-rc2-tip 2/15] 2: uprobes: Breakpoint insertion/removal in user space applications Srikar Dronamraju
2010-09-01 19:38   ` Peter Zijlstra
2010-08-25 13:41 ` [PATCHv11 2.6.36-rc2-tip 3/15] 3: uprobes: Slot allocation for Execution out of line(XOL) Srikar Dronamraju
2010-09-01 20:13   ` Peter Zijlstra
2010-09-03 16:40     ` Srikar Dronamraju
2010-09-03 16:51       ` Peter Zijlstra
2010-09-03 17:26         ` Srikar Dronamraju
2010-09-03 17:41           ` Peter Zijlstra
2010-09-06  5:38             ` Srikar Dronamraju
2010-09-03 17:25       ` Peter Zijlstra
2010-09-02  8:23   ` Peter Zijlstra
2010-09-02 17:47     ` Srikar Dronamraju
2010-09-03  7:26       ` Peter Zijlstra
2010-09-06 17:59         ` Srikar Dronamraju
2010-09-06 18:20           ` Peter Zijlstra
2010-09-06 18:28           ` Peter Zijlstra
2010-08-25 13:42 ` [PATCHv11 2.6.36-rc2-tip 4/15] 4: uprobes: x86 specific functions for user space breakpointing Srikar Dronamraju
2010-09-03 10:26   ` Andi Kleen [this message]
2010-09-03 17:48     ` Srikar Dronamraju
2010-09-03 18:00       ` Peter Zijlstra
2010-09-06  7:53       ` Andi Kleen
2010-09-06 13:44         ` Srikar Dronamraju
2010-09-06 14:16           ` Andi Kleen
2010-09-07  0:56           ` Masami Hiramatsu
2010-08-25 13:42 ` [PATCHv11 2.6.36-rc2-tip 5/15] 5: uprobes: Uprobes (un)registration and exception handling Srikar Dronamraju
2010-09-01 21:43   ` Peter Zijlstra
2010-09-02  8:12     ` Peter Zijlstra
2010-09-03 16:42     ` Srikar Dronamraju
2010-09-03 17:19       ` Peter Zijlstra
2010-09-06 17:46         ` Srikar Dronamraju
2010-09-06 18:15           ` Peter Zijlstra
2010-09-06 18:15           ` Peter Zijlstra
2010-09-07  6:48             ` Srikar Dronamraju
2010-09-07  9:33               ` Peter Zijlstra
2010-09-07 11:51                 ` Srikar Dronamraju
2010-09-07 12:25                   ` Peter Zijlstra
2010-09-06 18:25           ` Mathieu Desnoyers
2010-09-06 20:40           ` Christoph Hellwig
2010-09-06 21:06             ` Peter Zijlstra
2010-09-06 21:12               ` Christoph Hellwig
2010-09-06 21:18                 ` Peter Zijlstra
2010-09-07 12:02             ` Srikar Dronamraju
2010-09-07 16:47               ` Mathieu Desnoyers
2010-09-03 17:27       ` Peter Zijlstra
2010-09-01 21:46   ` Peter Zijlstra
2010-08-25 13:42 ` [PATCHv11 2.6.36-rc2-tip 6/15] 6: uprobes: X86 support for Uprobes Srikar Dronamraju
2010-08-25 13:42 ` [PATCHv11 2.6.36-rc2-tip 7/15] 7: uprobes: Uprobes Documentation Srikar Dronamraju
2010-08-25 13:42 ` [PATCHv11 2.6.36-rc2-tip 8/15] 8: tracing: Extract out common code for kprobes/uprobes traceevents Srikar Dronamraju
2010-08-25 13:43 ` [PATCHv11 2.6.36-rc2-tip 9/15] 9: tracing: uprobes trace_event interface Srikar Dronamraju
2010-08-25 13:43 ` [PATCHv11 2.6.36-rc2-tip 10/15] 10: tracing: config option to enable both kprobe-tracer and uprobe-tracer Srikar Dronamraju
2010-08-26  6:02   ` Masami Hiramatsu
2010-08-27  9:31     ` Srikar Dronamraju
2010-08-27 11:04       ` Masami Hiramatsu
2010-08-27 12:17         ` Srikar Dronamraju
2010-08-27 15:37           ` Masami Hiramatsu
2010-08-27 14:10     ` [PATCHv11a " Srikar Dronamraju
2010-08-25 13:43 ` [PATCHv11 2.6.36-rc2-tip 11/15] 11: perf: list symbols in a dso in ascending order Srikar Dronamraju
2010-08-25 23:21   ` Arnaldo Carvalho de Melo
2010-08-26  4:32     ` Srikar Dronamraju
2010-08-30  8:35   ` [tip:perf/core] perf symbols: List symbols in a dso in ascending name order tip-bot for Srikar Dronamraju
2010-08-25 13:43 ` [PATCHv11 2.6.36-rc2-tip 12/15] 12: perf: show possible probes in a given file Srikar Dronamraju
2010-08-27 14:21   ` [PATCHv11a " Srikar Dronamraju
2010-10-20  9:56     ` Masami Hiramatsu
2010-08-25 13:43 ` [PATCHv11 2.6.36-rc2-tip 13/15] 13: perf: Loop thro each of the maps in a map_group Srikar Dronamraju
2010-08-25 13:44 ` [PATCHv11 2.6.36-rc2-tip 14/15] 14: perf: perf interface for uprobes Srikar Dronamraju
2010-08-25 13:44 ` [PATCHv11 2.6.36-rc2-tip 15/15] 15: perf: Show Potential probe points Srikar Dronamraju
2010-10-29  9:23 ` [PATCHv11 2.6.36-rc2-tip 0/15] 0: Uprobes Patches Christoph Hellwig
2010-10-29 10:48   ` Srikar Dronamraju
2010-11-04 18:45     ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87pqwvm8cl.fsf@basil.nowhere.org \
    --to=andi@firstfloor.org \
    --cc=acme@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=ananth@in.ibm.com \
    --cc=fche@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=hch@infradead.org \
    --cc=jkenisto@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@elte.hu \
    --cc=mjw@redhat.com \
    --cc=naren.devaiah@in.ibm.com \
    --cc=oleg@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=rdunlap@xenotime.net \
    --cc=rostedt@goodmis.org \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox