[RFC][PATCH] x86: ptrace: Add function argument access API

[RFC][PATCH] x86: ptrace: Add function argument access API

[Steven Rostedt]

[
  A while ago I posted an RFC patchset for dynamic function based
  events. But Masami pointed out that this could be done with kprobes
  with minimal changes. He posted a patch set back in March
  http://lkml.kernel.org/r/152049860385.7289.14079393589900496424.stgit@devbox
  I've pulled this in locally, but haven't had the time until recently
  to look at it seriously. I even plan to talk about these changes in
  my talk at Open Source Summit in Edinburgh less than two weeks away
  (talk about conference driven development!).
  Anyway, the one patch that really needs external approval is the one
  that creates a new architecture dependent API to retrieve function
  arguments from pt_regs if the ip is at the start of the function call
  (via a breakpoint or ftrace fentry). That's this patch.

  Anyone have any issues with it? If not, I'm going to start doing some
  serious testing of this code and try to get it into the next merge
  window.

  Thanks!

  -- Steve
]

From: Masami Hiramatsu <mhiramat@kernel.org>

Add regs_get_argument() which returns N th argument of the
function call.
Note that this chooses most probably assignment, in some case
it can be incorrect (e.g. passing data structure or floating
point etc.)

This is expected to be called from kprobes or ftrace with regs
where the top of stack is the return address.

Link: http://lkml.kernel.org/r/152465885737.26224.2822487520472783854.stgit@devbox

Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
---
 arch/Kconfig                  |  7 +++++++
 arch/x86/Kconfig              |  1 +
 arch/x86/include/asm/ptrace.h | 38 +++++++++++++++++++++++++++++++++++
 3 files changed, 46 insertions(+)

diff --git a/arch/Kconfig b/arch/Kconfig
index 6801123932a5..facace0c90fc 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -290,6 +290,13 @@ config HAVE_RSEQ
 	  This symbol should be selected by an architecture if it
 	  supports an implementation of restartable sequences.
 
+config HAVE_FUNCTION_ARG_ACCESS_API
+	bool
+	help
+	  This symbol should be selected by an architecure if it supports
+	  the API needed to access function arguments from pt_regs,
+	  declared in asm/ptrace.h
+
 config HAVE_CLK
 	bool
 	help
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 1a0be022f91d..972973851779 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -184,6 +184,7 @@ config X86
 	select HAVE_RCU_TABLE_INVALIDATE	if HAVE_RCU_TABLE_FREE
 	select HAVE_REGS_AND_STACK_ACCESS_API
 	select HAVE_RELIABLE_STACKTRACE		if X86_64 && (UNWINDER_FRAME_POINTER || UNWINDER_ORC) && STACK_VALIDATION
+	select HAVE_FUNCTION_ARG_ACCESS_API
 	select HAVE_STACKPROTECTOR		if CC_HAS_SANE_STACKPROTECTOR
 	select HAVE_STACK_VALIDATION		if X86_64
 	select HAVE_RSEQ
diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h
index 6de1fd3d0097..c2304b25e2fd 100644
--- a/arch/x86/include/asm/ptrace.h
+++ b/arch/x86/include/asm/ptrace.h
@@ -256,6 +256,44 @@ static inline unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs,
 		return 0;
 }
 
+/**
+ * regs_get_kernel_argument() - get Nth function argument in kernel
+ * @regs:	pt_regs of that context
+ * @n:		function argument number (start from 0)
+ *
+ * regs_get_argument() returns @n th argument of the function call.
+ * Note that this chooses most probably assignment, in some case
+ * it can be incorrect.
+ * This is expected to be called from kprobes or ftrace with regs
+ * where the top of stack is the return address.
+ */
+static inline unsigned long regs_get_kernel_argument(struct pt_regs *regs,
+						     unsigned int n)
+{
+	static const unsigned int argument_offs[] = {
+#ifdef __i386__
+		offsetof(struct pt_regs, ax),
+		offsetof(struct pt_regs, cx),
+		offsetof(struct pt_regs, dx),
+#define NR_REG_ARGUMENTS 3
+#else
+		offsetof(struct pt_regs, di),
+		offsetof(struct pt_regs, si),
+		offsetof(struct pt_regs, dx),
+		offsetof(struct pt_regs, cx),
+		offsetof(struct pt_regs, r8),
+		offsetof(struct pt_regs, r9),
+#define NR_REG_ARGUMENTS 6
+#endif
+	};
+
+	if (n >= NR_REG_ARGUMENTS) {
+		n -= NR_REG_ARGUMENTS - 1;
+		return regs_get_kernel_stack_nth(regs, n);
+	} else
+		return regs_get_register(regs, argument_offs[n]);
+}
+
 #define arch_has_single_step()	(1)
 #ifdef CONFIG_X86_DEBUGCTLMSR
 #define arch_has_block_step()	(1)
-- 
2.19.0

Re: [RFC][PATCH] x86: ptrace: Add function argument access API

[Steven Rostedt]

On Thu, 11 Oct 2018 23:00:21 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

>   A while ago I posted an RFC patchset for dynamic function based
>   events. But Masami pointed out that this could be done with kprobes
>   with minimal changes. He posted a patch set back in March
>   http://lkml.kernel.org/r/152049860385.7289.14079393589900496424.stgit@devbox
>   I've pulled this in locally, but haven't had the time until recently
>   to look at it seriously. I even plan to talk about these changes in
>   my talk at Open Source Summit in Edinburgh less than two weeks away
>   (talk about conference driven development!).
>   Anyway, the one patch that really needs external approval is the one
>   that creates a new architecture dependent API to retrieve function
>   arguments from pt_regs if the ip is at the start of the function call
>   (via a breakpoint or ftrace fentry). That's this patch.
> 
>   Anyone have any issues with it? If not, I'm going to start doing some
>   serious testing of this code and try to get it into the next merge
>   window.

You can also play with the full repo here:

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git

 branch: ftrace/kprobes

-- Steve

Re: [RFC][PATCH] x86: ptrace: Add function argument access API

[Steven Rostedt]

Anyone have any issues with this patch?

-- Steve


On Thu, 11 Oct 2018 23:00:21 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> [
>   A while ago I posted an RFC patchset for dynamic function based
>   events. But Masami pointed out that this could be done with kprobes
>   with minimal changes. He posted a patch set back in March
>   http://lkml.kernel.org/r/152049860385.7289.14079393589900496424.stgit@devbox
>   I've pulled this in locally, but haven't had the time until recently
>   to look at it seriously. I even plan to talk about these changes in
>   my talk at Open Source Summit in Edinburgh less than two weeks away
>   (talk about conference driven development!).
>   Anyway, the one patch that really needs external approval is the one
>   that creates a new architecture dependent API to retrieve function
>   arguments from pt_regs if the ip is at the start of the function call
>   (via a breakpoint or ftrace fentry). That's this patch.
> 
>   Anyone have any issues with it? If not, I'm going to start doing some
>   serious testing of this code and try to get it into the next merge
>   window.
> 
>   Thanks!
> 
>   -- Steve
> ]
> 
> From: Masami Hiramatsu <mhiramat@kernel.org>
> 
> Add regs_get_argument() which returns N th argument of the
> function call.
> Note that this chooses most probably assignment, in some case
> it can be incorrect (e.g. passing data structure or floating
> point etc.)
> 
> This is expected to be called from kprobes or ftrace with regs
> where the top of stack is the return address.
> 
> Link: http://lkml.kernel.org/r/152465885737.26224.2822487520472783854.stgit@devbox
> 
> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
> ---
>  arch/Kconfig                  |  7 +++++++
>  arch/x86/Kconfig              |  1 +
>  arch/x86/include/asm/ptrace.h | 38 +++++++++++++++++++++++++++++++++++
>  3 files changed, 46 insertions(+)
> 
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 6801123932a5..facace0c90fc 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -290,6 +290,13 @@ config HAVE_RSEQ
>  	  This symbol should be selected by an architecture if it
>  	  supports an implementation of restartable sequences.
>  
> +config HAVE_FUNCTION_ARG_ACCESS_API
> +	bool
> +	help
> +	  This symbol should be selected by an architecure if it supports
> +	  the API needed to access function arguments from pt_regs,
> +	  declared in asm/ptrace.h
> +
>  config HAVE_CLK
>  	bool
>  	help
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 1a0be022f91d..972973851779 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -184,6 +184,7 @@ config X86
>  	select HAVE_RCU_TABLE_INVALIDATE	if HAVE_RCU_TABLE_FREE
>  	select HAVE_REGS_AND_STACK_ACCESS_API
>  	select HAVE_RELIABLE_STACKTRACE		if X86_64 && (UNWINDER_FRAME_POINTER || UNWINDER_ORC) && STACK_VALIDATION
> +	select HAVE_FUNCTION_ARG_ACCESS_API
>  	select HAVE_STACKPROTECTOR		if CC_HAS_SANE_STACKPROTECTOR
>  	select HAVE_STACK_VALIDATION		if X86_64
>  	select HAVE_RSEQ
> diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h
> index 6de1fd3d0097..c2304b25e2fd 100644
> --- a/arch/x86/include/asm/ptrace.h
> +++ b/arch/x86/include/asm/ptrace.h
> @@ -256,6 +256,44 @@ static inline unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs,
>  		return 0;
>  }
>  
> +/**
> + * regs_get_kernel_argument() - get Nth function argument in kernel
> + * @regs:	pt_regs of that context
> + * @n:		function argument number (start from 0)
> + *
> + * regs_get_argument() returns @n th argument of the function call.
> + * Note that this chooses most probably assignment, in some case
> + * it can be incorrect.
> + * This is expected to be called from kprobes or ftrace with regs
> + * where the top of stack is the return address.
> + */
> +static inline unsigned long regs_get_kernel_argument(struct pt_regs *regs,
> +						     unsigned int n)
> +{
> +	static const unsigned int argument_offs[] = {
> +#ifdef __i386__
> +		offsetof(struct pt_regs, ax),
> +		offsetof(struct pt_regs, cx),
> +		offsetof(struct pt_regs, dx),
> +#define NR_REG_ARGUMENTS 3
> +#else
> +		offsetof(struct pt_regs, di),
> +		offsetof(struct pt_regs, si),
> +		offsetof(struct pt_regs, dx),
> +		offsetof(struct pt_regs, cx),
> +		offsetof(struct pt_regs, r8),
> +		offsetof(struct pt_regs, r9),
> +#define NR_REG_ARGUMENTS 6
> +#endif
> +	};
> +
> +	if (n >= NR_REG_ARGUMENTS) {
> +		n -= NR_REG_ARGUMENTS - 1;
> +		return regs_get_kernel_stack_nth(regs, n);
> +	} else
> +		return regs_get_register(regs, argument_offs[n]);
> +}
> +
>  #define arch_has_single_step()	(1)
>  #ifdef CONFIG_X86_DEBUGCTLMSR
>  #define arch_has_block_step()	(1)

Re: [RFC][PATCH] x86: ptrace: Add function argument access API

[Andy Lutomirski]

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.

--Andy

Re: [RFC][PATCH] x86: ptrace: Add function argument access API

[Steven Rostedt]

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.
> 

100% agree. I'll add a patch on top of it to make the changes, and keep
what Masami had originally for full history.

Thanks for taking the time to take a look at it.

-- Steve

Re: [RFC][PATCH] x86: ptrace: Add function argument access API

[Steven Rostedt]

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.

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

Re: [RFC][PATCH] x86: ptrace: Add function argument access API

[Masami Hiramatsu]

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>

Re: [RFC][PATCH] x86: ptrace: Add function argument access API

[Steven Rostedt]

On Mon, 15 Oct 2018 23:56:46 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:

> 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.

Doing a git grep on regs_get_kernel_stack_nth(), I think you are right.
I'll resend and make the _nth() function just the _safe() function. No
need to do it without the probe_kernel_read() call.

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

Thanks,

-- Steve

> 
>

Re: [RFC][PATCH] x86: ptrace: Add function argument access API

[Steven Rostedt]

On Mon, 15 Oct 2018 23:56:46 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:

> 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>
> 

Hi Masami,

Can you review my v2 version which implements what you suggest.

Thanks,

-- Steve

Re: [RFC][PATCH] x86: ptrace: Add function argument access API

[Steven Rostedt]

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.
>

A patch to protect regs_within_kernel_stack() with
probe_kernel_read() has already been accepted. Can someone give an
Acked-by on this patch? As it does touch x86.

Thanks!

-- Steve