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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 19 May 2020 16:02:04 +0100
From:   Russell King - ARM Linux admin <>
To:     Andrew Jeffery <>
Subject: Re: [PATCH] ARM: Implement functions for HAVE_FUNCTION_ARG_ACCESS_API

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 <>
> ---
> 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:
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up

Powered by blists - more mailing lists