All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu <mhiramat@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Andy Lutomirski <luto@amacapital.net>,
	LKML <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>
Subject: Re: [RFC][PATCH] x86: ptrace: Add function argument access API
Date: Mon, 15 Oct 2018 23:56:46 +0900	[thread overview]
Message-ID: <20181015235646.2cbb7dc9bc4b7b54f900e0fb@kernel.org> (raw)
In-Reply-To: <20181012155439.59f77556@gandalf.local.home>

On Fri, 12 Oct 2018 15:54:39 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Fri, 12 Oct 2018 11:21:28 -0700
> Andy Lutomirski <luto@amacapital.net> wrote:
> 
> > On Fri, Oct 12, 2018 at 9:26 AM Steven Rostedt <rostedt@goodmis.org> wrote:
> > >
> > >
> > > Anyone have any issues with this patch?
> > >  
> > 
> > I'm conceptually okay with it.  That being said,
> > regs_within_kernel_stack(), which you're indirectly using, is
> > off-by-a-few.  And updating it to use probe_kernel_read() might be
> > nice for robustness.
> > 
> 
> Something like this?
> 
> -- Steve
> 
> From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
> Date: Fri, 12 Oct 2018 15:44:20 -0400
> Subject: [PATCH] x86: ptrace.h: Add regs_get_kernel_stack_nth_safe() function
> 
> Andy had some concerns about using regs_get_kernel_stack_nth() in a new
> function regs_get_kernel_argument() as if there's any error in the stack
> code, it could cause a bad memory access. Instead, add a new function called
> regs_get_kernel_stack_nth_safe() that does a probe_kernel_read() on the
> stack address to be extra careful in accessing the memory. To share the
> code, regs_get_kernel_stack_nth_addr() was added to just return the stack
> address (or NULL if not on the stack), that both regs_get_kernel_stack_nth()
> and the _safe() version can use.

This patch looks good to me.
But if the concern is real, all regs_get_kernel_stack_nth() user must move
onto _safe() version, at least all tracers code.

Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>

Thanks,

> 
> Link: http://lkml.kernel.org/r/CALCETrXn9zKTb9i1LP3qoFcpqZHF34BdkuZ5D3N0uCmRr+VnbA@mail.gmail.com
> Requested-by: Andy Lutomirski <luto@amacapital.net>
> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
> ---
>  arch/x86/include/asm/ptrace.h | 57 ++++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 54 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h
> index c2304b25e2fd..8df7ab6a17c5 100644
> --- a/arch/x86/include/asm/ptrace.h
> +++ b/arch/x86/include/asm/ptrace.h
> @@ -237,6 +237,27 @@ static inline int regs_within_kernel_stack(struct pt_regs *regs,
>  }
>  
>  /**
> + * regs_get_kernel_stack_nth_addr() - get the address of the Nth entry on stack
> + * @regs:	pt_regs which contains kernel stack pointer.
> + * @n:		stack entry number.
> + *
> + * regs_get_kernel_stack_nth() returns the address of the @n th entry of the
> + * kernel stack which is specified by @regs. If the @n th entry is NOT in
> + * the kernel stack, this returns NULL.
> + */
> +static inline unsigned long *regs_get_kernel_stack_nth_addr(struct pt_regs *regs,
> +							    unsigned int n)
> +{
> +	unsigned long *addr = (unsigned long *)kernel_stack_pointer(regs);
> +
> +	addr += n;
> +	if (regs_within_kernel_stack(regs, (unsigned long)addr))
> +		return addr;
> +	else
> +		return NULL;
> +}
> +
> +/**
>   * regs_get_kernel_stack_nth() - get Nth entry of the stack
>   * @regs:	pt_regs which contains kernel stack pointer.
>   * @n:		stack entry number.
> @@ -248,14 +269,44 @@ static inline int regs_within_kernel_stack(struct pt_regs *regs,
>  static inline unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs,
>  						      unsigned int n)
>  {
> -	unsigned long *addr = (unsigned long *)kernel_stack_pointer(regs);
> -	addr += n;
> -	if (regs_within_kernel_stack(regs, (unsigned long)addr))
> +	unsigned long *addr;
> +
> +	addr = regs_get_kernel_stack_nth_addr(regs, n);
> +	if (addr)
>  		return *addr;
>  	else
>  		return 0;
>  }
>  
> +/* To avoid include hell, we can't include uaccess.h */
> +extern long probe_kernel_read(void *dst, const void *src, size_t size);
> +
> +/**
> + * regs_get_kernel_stack_nth_safe() - safely get Nth entry of the stack
> + * @regs:	pt_regs which contains kernel stack pointer.
> + * @n:		stack entry number.
> + *
> + * Same as regs_get_kernel_stack_nth(), but references the stack value
> + * with a probe_kernel_read() in case there's a bad stack pointer, it
> + * will not cause a bad memory access. If the @n is not on the stack,
> + * or a bad memory access happened, it returns zero.
> + */
> +static inline unsigned long regs_get_kernel_stack_nth_safe(struct pt_regs *regs,
> +							   unsigned int n)
> +{
> +	unsigned long *addr;
> +	unsigned long val;
> +	long ret;
> +
> +	addr = regs_get_kernel_stack_nth_addr(regs, n);
> +	if (addr) {
> +		ret = probe_kernel_read(&val, addr, sizeof(val));
> +		if (!ret)
> +			return val;
> +	}
> +	return 0;
> +}
> +
>  /**
>   * regs_get_kernel_argument() - get Nth function argument in kernel
>   * @regs:	pt_regs of that context
> -- 
> 2.13.6
> 


-- 
Masami Hiramatsu <mhiramat@kernel.org>

  reply	other threads:[~2018-10-15 14:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-12  3:00 [RFC][PATCH] x86: ptrace: Add function argument access API Steven Rostedt
2018-10-12  3:01 ` Steven Rostedt
2018-10-12 16:26 ` Steven Rostedt
2018-10-12 18:21   ` Andy Lutomirski
2018-10-12 18:22     ` Steven Rostedt
2018-10-12 19:54     ` Steven Rostedt
2018-10-15 14:56       ` Masami Hiramatsu [this message]
2018-10-16 18:59         ` Steven Rostedt
2018-10-18  2:34         ` Steven Rostedt
2018-10-27 14:58     ` Steven Rostedt

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=20181015235646.2cbb7dc9bc4b7b54f900e0fb@kernel.org \
    --to=mhiramat@kernel.org \
    --cc=hpa@zytor.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /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.