linux-kernel - Re: [PATCH] ARM: Add 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] [thread-next>] [day] [month] [year] [list]

Date: Tue, 4 Jun 2024 09:36:04 +0800
From: Jinjie Ruan <ruanjinjie@...wei.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
CC: <oleg@...hat.com>, <arnd@...db.de>, <afd@...com>,
	<akpm@...ux-foundation.org>, <linus.walleij@...aro.org>,
	<eric.devolder@...cle.com>, <robh@...nel.org>,
	<linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ARM: Add HAVE_FUNCTION_ARG_ACCESS_API support



On 2024/6/3 16:39, Russell King (Oracle) wrote:
> On Mon, Jun 03, 2024 at 03:37:51PM +0800, Jinjie Ruan wrote:
>> Currently, kprobe on ARM32 can not use the '$argx' syntax available on
>> other architecture. So implement regs_get_kernel_argument() and add
>> HAVE_FUNCTION_ARG_ACCESS_API support.
> 
> This may work in the simple case, but it just doesn't work in the
> general case, where a function accepts 64-bit arguments. For example,
> for EABI and a function taking a 64-bit argument followed by a 32-bit
> argument:
> 
> 	R0/R1 = 64-bit argument
> 	R2 = 32-bit argument
> 
> Now consider 32-bit argument followed by 64-bit argument:
> 
> 	R0 = 32-bit argument
> 	R1 = unused
> 	R2/R3 = 64-bit argument

I agree with you, the current implementation considers a very simple
case, where all parameters are 32-bit.

>From "Procedure Call Standard for the Arm® Architecture", the
"6.1.1.1 Handling values larger than 32 bits" describes it this way:

A double-word sized type is passed in two consecutive registers (e.g.,
r0 and r1, or r2 and r3).

> 
> Note that the mapping isn't argN = RN.
> 
> Also, given that "unsigned long" is 32-bit on 32-bit Arm, one can't
> return a 64-bit argument through this interface. Even if one typed
> the function as u64, it still wouldn't work because the caller
> assigns the return value to an unsigned long. This seems to be an
> issue throughout the kernel tracing - it isn't written to support

How about updating this interface to solve this problem? Let
regs_get_kernel_argument() return u64.

> 64-bit arguments on 32-bit architectures. See, for example,
> fetch_store_raw(), where the unsigned long gets cast to a u64.
> It'll still only have 32-bits of significant value.
>