This allows extraction of kernel function arguments via kprobes on ARM.
Based on the arm64 implementation and adapted for the 32-bit AAPCS.
Signed-off-by: Andrew Jeffery <[email protected]>
---
The description for HAVE_FUNCTION_ARG_ACCESS_API was pretty vague on what was
required. I've implemented enough to enable argument extraction for kprobes; is
there anything else needed to satisfy HAVE_FUNCTION_ARG_ACCESS_API?
arch/arm/Kconfig | 1 +
arch/arm/include/asm/ptrace.h | 24 ++++++++++++++++++++++++
2 files changed, 25 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c77c93c485a0..d82f80845e03 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -82,6 +82,7 @@ config ARM
select HAVE_EXIT_THREAD
select HAVE_FAST_GUP if ARM_LPAE
select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL
+ select HAVE_FUNCTION_ARG_ACCESS_API
select HAVE_FUNCTION_GRAPH_TRACER if !THUMB2_KERNEL && !CC_IS_CLANG
select HAVE_FUNCTION_TRACER if !XIP_KERNEL && (CC_IS_GCC || CLANG_VERSION >= 100000)
select HAVE_GCC_PLUGINS
diff --git a/arch/arm/include/asm/ptrace.h b/arch/arm/include/asm/ptrace.h
index 91d6b7856be4..71e7649deac9 100644
--- a/arch/arm/include/asm/ptrace.h
+++ b/arch/arm/include/asm/ptrace.h
@@ -149,6 +149,30 @@ static inline unsigned long regs_get_register(struct pt_regs *regs,
return *(unsigned long *)((unsigned long)regs + offset);
}
+/*
+ * Read a register given an architectural register index r.
+ */
+static inline unsigned long pt_regs_read_reg(const struct pt_regs *regs, int r)
+{
+ return regs->uregs[r];
+}
+
+/**
+ * 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.
+ */
+static inline unsigned long regs_get_kernel_argument(struct pt_regs *regs,
+ unsigned int n)
+{
+#define NR_REG_ARGUMENTS 4
+ if (n < NR_REG_ARGUMENTS)
+ return pt_regs_read_reg(regs, n);
+ return 0;
+}
+
/* Valid only for Kernel mode traps. */
static inline unsigned long kernel_stack_pointer(struct pt_regs *regs)
{
--
2.25.1
On Wed, May 20, 2020 at 12:01:32AM +0930, Andrew Jeffery wrote:
> This allows extraction of kernel function arguments via kprobes on ARM.
> Based on the arm64 implementation and adapted for the 32-bit AAPCS.
>
> Signed-off-by: Andrew Jeffery <[email protected]>
> ---
> The description for HAVE_FUNCTION_ARG_ACCESS_API was pretty vague on what was
> required. I've implemented enough to enable argument extraction for kprobes; is
> there anything else needed to satisfy HAVE_FUNCTION_ARG_ACCESS_API?
What about 64-bit arguments? How do they get handled?
regs_get_kernel_argument() talks about 'n' being the argument number,
and maps this directly to a register. If a function argument
prototype is:
(something *foo, long long bar, int baz)
The foo is in r0, bar is in r2/r3 on EABI, and baz is on the stack.
n=0 will return foo. n=1 will be undefined. n=2 will return part of
bar, and n=3 will return the other half. Is this what is expected?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
Hi Russell,
On Wed, 20 May 2020, at 00:32, Russell King - ARM Linux admin wrote:
> On Wed, May 20, 2020 at 12:01:32AM +0930, Andrew Jeffery wrote:
> > This allows extraction of kernel function arguments via kprobes on ARM.
> > Based on the arm64 implementation and adapted for the 32-bit AAPCS.
> >
> > Signed-off-by: Andrew Jeffery <[email protected]>
> > ---
> > The description for HAVE_FUNCTION_ARG_ACCESS_API was pretty vague on what was
> > required. I've implemented enough to enable argument extraction for kprobes; is
> > there anything else needed to satisfy HAVE_FUNCTION_ARG_ACCESS_API?
>
> What about 64-bit arguments? How do they get handled?
>
> regs_get_kernel_argument() talks about 'n' being the argument number,
> and maps this directly to a register. If a function argument
> prototype is:
>
> (something *foo, long long bar, int baz)
>
> The foo is in r0, bar is in r2/r3 on EABI, and baz is on the stack.
>
> n=0 will return foo. n=1 will be undefined. n=2 will return part of
> bar, and n=3 will return the other half. Is this what is expected?
Certainly doesn't feel right, however the broken behaviour seems to be a
compromise accepted in the existing couple of implementations for arm64
and x86. The API prototype doesn't give us any type information, so we're
left to guess.
Here's the commentary from the others:
arch/x86/include/asm/ptrace.h:
```
/**
* 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)
{
...
```
arch/arm64/include/asm/ptrace.h:
```
/**
* 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 the most likely register mapping. In very rare
* cases this may not return correct data, for example, if one of the
* function parameters is 16 bytes or bigger. In such cases, we cannot
* get access the parameter correctly and the register assignment of
* subsequent parameters will be shifted.
*/
static inline unsigned long regs_get_kernel_argument(struct pt_regs *regs,
unsigned int n)
{
...
```
As for handling arguments on the stack, arm64 doesn't and I cribbed from
that:
```
static inline unsigned long regs_get_kernel_argument(struct pt_regs *regs,
unsigned int n)
{
#define NR_REG_ARGUMENTS 8
if (n < NR_REG_ARGUMENTS)
return pt_regs_read_reg(regs, n);
return 0;
}
```
Would you accept a v2 that adds stack argument handling but leaves the
¯\_(ツ)_/¯ ABI behaviour? Or will I need to fix the API?
Thanks for the quick response.
Andrew