All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Anton Arapov <anton@redhat.com>
Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Josh Stone <jistone@redhat.com>, Frank Eigler <fche@redhat.com>,
	Anithra P Janakiraman <anithra@linux.vnet.ibm.com>
Subject: Re: [RFC PATCH 1/6] uretprobes/x86: hijack return address
Date: Sat, 22 Dec 2012 17:02:12 +0100	[thread overview]
Message-ID: <20121222160212.GA18082@redhat.com> (raw)
In-Reply-To: <1356088596-17858-2-git-send-email-anton@redhat.com>

On 12/21, Anton Arapov wrote:
>
> +extern unsigned long
> +arch_uretprobe_hijack_return_addr(unsigned long rp_trampoline_vaddr, struct pt_regs *regs)
> +{
> +	struct uprobe_task *utask = current->utask;
> +	int rasize, ncopied;
> +	unsigned long orig_return_vaddr = 0; /* clear high bits for 32-bit apps */
> +
> +	if (is_ia32_task())
> +		rasize = 4;
> +	else
> +		rasize = 8;
> +
> +	ncopied = copy_from_user(&orig_return_vaddr, (void __user *)regs->sp, rasize);
> +	if (unlikely(ncopied))
> +		return -EFAULT;

Hmm. The caller (added by 3/6) does

	ri->orig_return_vaddr = arch_uretprobe_hijack_return_addr(...);
	if (likely(ri->orig_return_vaddr)) {


> +	ncopied = copy_to_user((void __user *)regs->sp, &rp_trampoline_vaddr, rasize);
> +	if (unlikely(ncopied)) {
> +		if (ncopied != rasize) {
> +			printk(KERN_ERR "uretprobe: return address clobbered: "
> +					"pid=%d, %%sp=%#lx, %%ip=%#lx\n",
> +					current->pid, regs->sp, regs->ip);

OK... perhaps we could try to write rasize - ncopied bytes first, but
this is minor.

> +			utask->doomed = true;

But this looks strange. We set ->doomed = true, but the task continues to run.
I think in this case we should send SIGTRAP right now. We should not wait until
handle_swbp() notices this flag (which btw can never happen). And this also
means ->doomed should die.

> +		return -EFAULT;

Again, NULL or fix the caller.

> + * On x86_32, if a function returns a struct or union, the return
> + * value is copied into an area created by the caller. The address
> + * of this area is passed on the stack as a "hidden" first argument.
> + * When such a function returns, it uses a "ret $4" instruction to pop
> + * not only the return address but also the hidden arg.  To accommodate
> + * such functions, we add 4 bytes of slop when predicting the return
> + * address. See PR #10078.
                   ^^^^^^^^^
I'd wish I knew what this "PR" means ;)


> +#define STRUCT_RETURN_SLOP 4
> +
> +extern unsigned long
> +arch_uretprobe_predict_sp_at_return(struct pt_regs *regs, struct task_struct *tsk)
> +{
> +	if (test_tsk_thread_flag(tsk, TIF_IA32))
> +		return (unsigned long) (regs->sp + 4 + STRUCT_RETURN_SLOP);

Somehow I can't understand the logic behind arch_uretprobe_predict_sp_at_return()
at all... I'll try more. but tsk is always current, I see no point to pass the
argument.

> @@ -60,6 +63,12 @@ struct uprobe_task {
>
>  	unsigned long			xol_vaddr;
>  	unsigned long			vaddr;
> +
> +	/*
> +	 * Unexpected error in probe point handling has left task's
> +	 * text or stack corrupted. Kill task ASAP.
                                    ^^^^^^^^^^^^^^
Exactly, so ...

> +	bool				doomed;

must die, I think.

Oleg.


  reply	other threads:[~2012-12-22 16:02 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-21 11:16 [RFC PATCH 0/6] uprobes: return probe implementation Anton Arapov
2012-12-21 11:16 ` [RFC PATCH 1/6] uretprobes/x86: hijack return address Anton Arapov
2012-12-22 16:02   ` Oleg Nesterov [this message]
2012-12-21 11:16 ` [RFC PATCH 2/6] uretprobes: trampoline implementation Anton Arapov
2012-12-22 16:02   ` Oleg Nesterov
2012-12-21 11:16 ` [RFC PATCH 3/6] uretprobes: return probe entry, prepare uretprobe Anton Arapov
2012-12-22 16:02   ` Oleg Nesterov
2012-12-21 11:16 ` [RFC PATCH 4/6] uretprobes: invoke return probe handlers Anton Arapov
2012-12-22 16:29   ` Oleg Nesterov
2012-12-21 11:16 ` [RFC PATCH 5/6] uprobes: add bp_vaddr argument to consumer handler Anton Arapov
2012-12-22 16:35   ` Oleg Nesterov
2012-12-22 17:13     ` Oleg Nesterov
2012-12-23 15:49       ` Oleg Nesterov
2013-01-08 14:27         ` Anton Arapov
2013-01-10 22:43           ` Josh Stone
2013-01-12 17:06             ` Oleg Nesterov
2013-01-15 19:15               ` Josh Stone
2013-01-16 16:20                 ` Oleg Nesterov
2012-12-21 11:16 ` [RFC PATCH 6/6] uretprobes: register() and unregister() implementation Anton Arapov
2012-12-22 16:38   ` Oleg Nesterov
2012-12-21 17:37 ` [RFC PATCH 0/6] uprobes: return probe implementation Oleg Nesterov

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=20121222160212.GA18082@redhat.com \
    --to=oleg@redhat.com \
    --cc=anithra@linux.vnet.ibm.com \
    --cc=anton@redhat.com \
    --cc=fche@redhat.com \
    --cc=jistone@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=srikar@linux.vnet.ibm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.