All of lore.kernel.org
 help / color / mirror / Atom feed
From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <peterz@infradead.org>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	Anton Arapov <anton@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Roland McGrath <roland@hack.frob.com>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/7] uprobes: Do not (ab)use TIF_SINGLESTEP/user_*_single_step() for single-stepping
Date: Fri, 7 Sep 2012 20:41:11 +0530	[thread overview]
Message-ID: <20120907151111.GQ30238@linux.vnet.ibm.com> (raw)
In-Reply-To: <20120903152613.GA9078@redhat.com>

* Oleg Nesterov <oleg@redhat.com> [2012-09-03 17:26:13]:

> user_enable/disable_single_step() was designed for ptrace, it assumes
> a single user and does unnecessary and wrong things for uprobes. For
> example:
> 
> 	- arch_uprobe_enable_step() can't trust TIF_SINGLESTEP, an
> 	  application itself can set X86_EFLAGS_TF which must be
> 	  preserved after arch_uprobe_disable_step().
> 
> 	- we do not want to set TIF_SINGLESTEP/TIF_FORCED_TF in
> 	  arch_uprobe_enable_step(), this only makes sense for ptrace.
> 
> 	- otoh we leak TIF_SINGLESTEP if arch_uprobe_disable_step()
> 	  doesn't do user_disable_single_step(), the application will
> 	  be killed after the next syscall.
> 
> 	- arch_uprobe_enable_step() does access_process_vm() we do
> 	  not need/want.
> 
> Change arch_uprobe_enable/disable_step() to set/clear X86_EFLAGS_TF
> directly, this is much simpler and more correct. However, we need to
> clear TIF_BLOCKSTEP/DEBUGCTLMSR_BTF before executing the probed insn,
> add set_task_blockstep(false).
> 
> Note: with or without this patch, there is another (hopefully minor)
> problem. A probed "pushf" insn can see the wrong X86_EFLAGS_TF set by
> uprobes. Perhaps we should change _disable to update the stack, or
> teach arch_uprobe_skip_sstep() to emulate this insn.
> 
> Signed-off-by: Oleg Nesterov <oleg@redhat.com>

Acked-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>

> ---
>  arch/x86/include/asm/processor.h |    2 ++
>  arch/x86/kernel/step.c           |    2 +-
>  arch/x86/kernel/uprobes.c        |   32 ++++++++++++++++++--------------
>  3 files changed, 21 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> index d048cad..433d2e5 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -759,6 +759,8 @@ static inline void update_debugctlmsr(unsigned long debugctlmsr)
>  	wrmsrl(MSR_IA32_DEBUGCTLMSR, debugctlmsr);
>  }
> 
> +extern void set_task_blockstep(struct task_struct *task, bool on);
> +
>  /*
>   * from system description table in BIOS. Mostly for MCA use, but
>   * others may find it useful:
> diff --git a/arch/x86/kernel/step.c b/arch/x86/kernel/step.c
> index f89cdc6..cd3b243 100644
> --- a/arch/x86/kernel/step.c
> +++ b/arch/x86/kernel/step.c
> @@ -157,7 +157,7 @@ static int enable_single_step(struct task_struct *child)
>  	return 1;
>  }
> 
> -static void set_task_blockstep(struct task_struct *task, bool on)
> +void set_task_blockstep(struct task_struct *task, bool on)
>  {
>  	unsigned long debugctl;
> 
> diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
> index 309a0e0..3b4aae6 100644
> --- a/arch/x86/kernel/uprobes.c
> +++ b/arch/x86/kernel/uprobes.c
> @@ -683,26 +683,30 @@ bool arch_uprobe_skip_sstep(struct arch_uprobe *auprobe, struct pt_regs *regs)
> 
>  void arch_uprobe_enable_step(struct arch_uprobe *auprobe)
>  {
> -	struct uprobe_task	*utask		= current->utask;
> -	struct arch_uprobe_task	*autask		= &utask->autask;
> +	struct task_struct *task = current;

Any particular reason to use task instead of current?

> +	struct arch_uprobe_task	*autask	= &task->utask->autask;
> +	struct pt_regs *regs = task_pt_regs(task);
> 
>  	autask->restore_flags = 0;
> -	if (!test_tsk_thread_flag(current, TIF_SINGLESTEP) &&
> -			!(auprobe->fixups & UPROBE_FIX_SETF))
> +	if (!(regs->flags & X86_EFLAGS_TF) &&
> +	    !(auprobe->fixups & UPROBE_FIX_SETF))
>  		autask->restore_flags |= UPROBE_CLEAR_TF;
> -	/*
> -	 * The state of TIF_BLOCKSTEP is not saved. With the TF flag set we
> -	 * would to examine the opcode and the flags to make it right. Without
> -	 * TF block stepping makes no sense.
> -	 */
> -	user_enable_single_step(current);
> +
> +	regs->flags |= X86_EFLAGS_TF;
> +	if (test_tsk_thread_flag(task, TIF_BLOCKSTEP))
> +		set_task_blockstep(task, false);
>  }
> 
>  void arch_uprobe_disable_step(struct arch_uprobe *auprobe)
>  {
> -	struct uprobe_task *utask		= current->utask;
> -	struct arch_uprobe_task	*autask		= &utask->autask;
> -
> +	struct task_struct *task = current;
> +	struct arch_uprobe_task	*autask	= &task->utask->autask;
> +	struct pt_regs *regs = task_pt_regs(task);
> +	/*
> +	 * The state of TIF_BLOCKSTEP was not saved so we can get an extra
> +	 * SIGTRAP if we do not clear TF. We need to examine the opcode to
> +	 * make it right.
> +	 */
>  	if (autask->restore_flags & UPROBE_CLEAR_TF)
> -		user_disable_single_step(current);
> +		regs->flags &= ~X86_EFLAGS_TF;
>  }
> -- 
> 1.5.5.1
> 


  reply	other threads:[~2012-09-07 15:14 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-03 15:25 [PATCH 0/7] uprobes: single-step fixes Oleg Nesterov
2012-09-03 15:25 ` [PATCH 1/7] uprobes: Introduce arch_uprobe_enable/disable_step() Oleg Nesterov
2012-09-07 14:57   ` Srikar Dronamraju
2012-09-03 15:26 ` [PATCH 2/7] uprobes: x86: Implement x86 specific arch_uprobe_*_step Oleg Nesterov
2012-09-07 14:59   ` Srikar Dronamraju
2012-09-03 15:26 ` [PATCH 3/7] ptrace: Introduce set_task_blockstep() helper Oleg Nesterov
2012-09-07 15:00   ` Srikar Dronamraju
2012-09-03 15:26 ` [PATCH 4/7] ptrace: Partly fix set_task_blockstep()->update_debugctlmsr() logic Oleg Nesterov
2012-09-07 15:14   ` Srikar Dronamraju
2012-09-10 16:57   ` Sebastian Andrzej Siewior
2012-09-10 17:45     ` Peter Zijlstra
2012-09-10 17:27   ` Oleg Nesterov
2012-09-03 15:26 ` [PATCH 5/7] uprobes: Do not (ab)use TIF_SINGLESTEP/user_*_single_step() for single-stepping Oleg Nesterov
2012-09-07 15:11   ` Srikar Dronamraju [this message]
2012-09-07 15:50     ` Oleg Nesterov
2012-09-08  7:49       ` Srikar Dronamraju
2012-09-03 15:26 ` [PATCH 6/7] uprobes: Xol should send SIGTRAP if X86_EFLAGS_TF was set Oleg Nesterov
2012-09-12 12:08   ` Srikar Dronamraju
2012-09-12 14:45     ` Oleg Nesterov
2012-09-03 15:26 ` [PATCH 7/7] uprobes: Make arch_uprobe_task->saved_trap_nr "unsigned int" Oleg Nesterov
2012-09-12 12:27   ` Srikar Dronamraju
2012-09-08 17:06 ` [PATCH 0/7] uprobes: single-step fixes Oleg Nesterov
2012-09-12 12:33   ` Srikar Dronamraju
2012-09-08 17:06 ` [PATCH 8/7] uprobes: Fix arch_uprobe_disable_step() && UTASK_SSTEP_TRAPPED interaction Oleg Nesterov
2012-09-12 12:36   ` Srikar Dronamraju
2012-09-10 16:57 ` [PATCH 0/7] uprobes: single-step fixes Sebastian Andrzej Siewior

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=20120907151111.GQ30238@linux.vnet.ibm.com \
    --to=srikar@linux.vnet.ibm.com \
    --cc=ananth@in.ibm.com \
    --cc=anton@redhat.com \
    --cc=bigeasy@linutronix.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=roland@hack.frob.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 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.