linux-kernel - Re: [PATCH] ARM: Implement functions for HAVE_FUNCTION_ARG_ACCESS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 20 May 2020 10:14:23 +0930
From:   "Andrew Jeffery" <andrew@...id.au>
To:     "Russell King" <linux@...linux.org.uk>
Cc:     linux-arm-kernel@...ts.infradead.org, oleg@...hat.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ARM: Implement functions for HAVE_FUNCTION_ARG_ACCESS_API

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 <andrew@...id.au>
> > ---
> > 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