linux-kernel - Re: [PATCH] MIPS: Export syscall stack arguments properly for remote use

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]

Message-ID: <Z63bEfoSJnLumOCa@alpha.franken.de>
Date: Thu, 13 Feb 2025 12:44:17 +0100
From: Thomas Bogendoerfer <tsbogend@...ha.franken.de>
To: "Maciej W. Rozycki" <macro@...am.me.uk>
Cc: Oleg Nesterov <oleg@...hat.com>, "Dmitry V. Levin" <ldv@...ace.io>,
	Jiaxun Yang <jiaxun.yang@...goat.com>, linux-mips@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] MIPS: Export syscall stack arguments properly for remote
 use

On Tue, Feb 11, 2025 at 06:22:30PM +0000, Maciej W. Rozycki wrote:
> We have several places across the kernel where we want to access another 
> task's syscall arguments, such as ptrace(2), seccomp(2), etc., by making 
> a call to syscall_get_arguments().
> 
> This works for register arguments right away by accessing the task's 
> `regs' member of `struct pt_regs', however for stack arguments seen with 
> 32-bit/o32 kernels things are more complicated.  Technically they ought 
> to be obtained from the user stack with calls to an access_remote_vm(), 
> but we have an easier way available already.
> 
> So as to be able to access syscall stack arguments as regular function 
> arguments following the MIPS calling convention we copy them over from 
> the user stack to the kernel stack in arch/mips/kernel/scall32-o32.S, in 
> handle_sys(), to the current stack frame's outgoing argument space at 
> the top of the stack, which is where the handler called expects to see 
> its incoming arguments.  This area is also pointed at by the `pt_regs'
> pointer obtained by task_pt_regs().
> 
> Make the o32 stack argument space a proper member of `struct pt_regs' 
> then, by renaming the existing member from `pad0' to `args' and using 
> generated offsets to access the space.  No functional change though.
> 
> With the change in place the o32 kernel stack frame layout at the entry 
> to a syscall handler invoked by handle_sys() is therefore as follows:
> 
> $sp + 68 -> |         ...         | <- pt_regs.regs[9]
>             +---------------------+
> $sp + 64 -> |         $t0         | <- pt_regs.regs[8]
>             +---------------------+
> $sp + 60 -> |   $a3/argument #4   | <- pt_regs.regs[7]
>             +---------------------+
> $sp + 56 -> |   $a2/argument #3   | <- pt_regs.regs[6]
>             +---------------------+
> $sp + 52 -> |   $a1/argument #2   | <- pt_regs.regs[5]
>             +---------------------+
> $sp + 48 -> |   $a0/argument #1   | <- pt_regs.regs[4]
>             +---------------------+
> $sp + 44 -> |         $v1         | <- pt_regs.regs[3]
>             +---------------------+
> $sp + 40 -> |         $v0         | <- pt_regs.regs[2]
>             +---------------------+
> $sp + 36 -> |         $at         | <- pt_regs.regs[1]
>             +---------------------+
> $sp + 32 -> |        $zero        | <- pt_regs.regs[0]
>             +---------------------+
> $sp + 28 -> |  stack argument #8  | <- pt_regs.args[7]
>             +---------------------+
> $sp + 24 -> |  stack argument #7  | <- pt_regs.args[6]
>             +---------------------+
> $sp + 20 -> |  stack argument #6  | <- pt_regs.args[5]
>             +---------------------+
> $sp + 16 -> |  stack argument #5  | <- pt_regs.args[4]
>             +---------------------+
> $sp + 12 -> | psABI space for $a3 | <- pt_regs.args[3]
>             +---------------------+
> $sp +  8 -> | psABI space for $a2 | <- pt_regs.args[2]
>             +---------------------+
> $sp +  4 -> | psABI space for $a1 | <- pt_regs.args[1]
>             +---------------------+
> $sp +  0 -> | psABI space for $a0 | <- pt_regs.args[0]
>             +---------------------+
> 
> holding user data received and with the first 4 frame slots reserved by 
> the psABI for the compiler to spill the incoming arguments from $a0-$a3 
> registers (which it sometimes does according to its needs) and the next 
> 4 frame slots designated by the psABI for any stack function arguments 
> that follow.  This data is also available for other tasks to peek/poke 
> at as reqired and where permitted.
> 
> Signed-off-by: Maciej W. Rozycki <macro@...am.me.uk>
> ---
>  arch/mips/include/asm/ptrace.h |    4 ++--
>  arch/mips/kernel/asm-offsets.c |    6 ++++++
>  arch/mips/kernel/scall32-o32.S |    8 ++++----
>  3 files changed, 12 insertions(+), 6 deletions(-)

applied to mips-fixes

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]